Drubix

Docs / Remediation guide

Fixing what Drubix finds

Every finding in your dashboard comes with a suggested fix. This guide explains each type of finding in plain English, why it matters, and the practical ways to fix it.

Where to start

  1. Fix critical and high findings first, especially anything marked as actively exploited.
  2. Outdated modules are the most common serious issue. A fix PR handles them in one click.
  3. Security headers and exposed files are usually fixed once in your server or CDN settings, and then they're fixed for good.
  4. After deploying a fix, click Scan now. The finding closes when Drubix sees the fix live.

Outdated core or modules

What it means: the site runs a version of Drupal core, a module, or a PHP library it depends on (Symfony, Guzzle, Twig and so on) that has a published security advisory, which makes it a known, documented way in. These are the findings to fix first.

"Confirmed" or "possible"? A confirmed finding means Drubix knows the exact installed version, from GitHub or the connector. A possible exposure means the module is there but its version couldn't be read from outside. Connect GitHub or install the connector to confirm it either way.

The quick way: a fix PR

With the site's repository connected to GitHub, click Create fix PR on the finding. Drubix opens a pull request that updates composer.json and composer.lock to the fixed version, including every core package together for a core fix. When several sites are affected, use Fix on all N sites. To have patch-level fixes merged automatically after your CI passes, turn on Autopilot.

The steps either way

  1. Read the release notesCheck the module's release notes, not just the advisory, for breaking changes.
  2. Update the codeMerge the fix PR, or run the command shown on the finding, for example: 
    composer require drupal/webform:^6.2.12 --with-all-dependencies
    A fix PR already includes the new composer.lock.
  3. Test on staging firstNever upgrade directly on production.
  4. Run database updates and clear caches 
    drush updatedb -y
drush cr
  5. Deploy and re-checkDeploy to production, then click Scan now in Drubix. The finding moves to Resolved once the new version is live.

Can't update today? Block it at the firewall

When an update has to wait (a code freeze, a client sign-off, a big upgrade), click Temporary firewall rule on the finding. Drubix reads the module's routes from the exact release the site runs and gives you a rule that blocks the module's public URLs, for Cloudflare, Nginx or Apache. Admin pages and ordinary Drupal pages (nodes, users) are never in it.

It's a stopgap, not a fix. While the rule is on, visitors get a 403 on those URLs, so the module's public features (its forms, for example) stop working. The vulnerability may also be reachable some other way. Update as soon as you can, then remove the rule. There's no rule for Drupal core or PHP libraries, because their code runs on every page.

Security headers

What it means: the site doesn't send some of the response headers that tell browsers to block common attacks, such as clickjacking, content-type tricks and insecure connections. It's the most common finding, and it only needs fixing in one place. Pick whichever matches your hosting:

Option A: at the CDN

If the site is behind a CDN such as Cloudflare or Fastly, this is usually easiest, and it works even when you can't change the server. In Cloudflare, use Rules → Transform Rules → Modify Response Header. No code changes are needed.

Option B: in the web server

This applies to every request, whatever the application does. For Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;" always;

For Apache, in .htaccess or the vhost:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

Option C: inside Drupal

Install the Security Kit (seckit) module and configure it at /admin/config/system/seckit. This is useful when someone else manages the hosting.

Take Content-Security-Policy slowly. It's the header most likely to break a live site, by blocking inline scripts, tag managers or third-party widgets. Send it as Content-Security-Policy-Report-Only for a week or two, review what it would have blocked, and only then switch to the enforcing header.

Exposed files

What it means: files that should never be public can be downloaded from the site. This is usually caused by the deploy process copying too much, not by the code.

Also block hidden files and the lock file at the web server. For Nginx:

location ~ /\.(?!well-known) { deny all; }
location ~ /composer\.(json|lock)$ { deny all; }

Unmaintained modules

What it means: nobody maintains the module any more. It may be safe today, but if a vulnerability is found, no fix will come. Options, best first:

  1. Switch to an actively maintained module, or a fork, that does the same job. Check the module's drupal.org page for suggestions.
  2. Ask whether the site still needs it. Sometimes the best fix is removing it.
  3. As a last resort, for a small module you need, move it into your own codebase, so maintaining it becomes a deliberate choice.

Permissions & security settings

What it means: a setting inside Drupal makes the site easier to attack. These findings need the connector module, because they can't be seen from outside.

Admin accounts

What it means: something about who can administer the site needs a look. These findings need the connector module.

Secrets in the repo

What it means: a password, API key, private key, .env file or database dump is committed to the site's GitHub repository. Anyone who can see the repo, now or later, can use it. These findings need GitHub connected.

  1. Rotate it firstChange the password or revoke the key with the service that issued it. Deleting the file doesn't remove it from git history, so rotating is the step that actually protects you.
  2. Remove it from the codeLoad it from an environment variable or your host's secrets settings instead. For Drupal database settings, read them with getenv() in settings.php.
  3. Stop it happening againAdd .env, *.sql and key files to .gitignore, and commit example files with placeholder values.

Email & DNS

What it means: the client's domain is easy to impersonate by email, or a subdomain points at a service that no longer exists.

Custom code

What it means: a pattern in the site's own modules, themes or templates that often leads to a vulnerability. Security advisories never cover custom code, so this is the only check it gets. These findings need GitHub connected, and each one is a lead for a developer to confirm, not a proven bug.

If a flagged line is safe, add a drubix:ignore comment on it and the finding disappears on the next scan.

Changed or unknown files

What it means: once a day the connector compares Drupal core and every contrib module and theme with the official release from drupal.org. These are the findings that most often mean a site has already been hacked.

Run the check on demand with drush drubix:integrity.

Page tampering

What it means: once a day Drubix opens the homepage and a few key pages (login, checkout, contact) in a real browser, the way a visitor would, and checks what actually loads. The first check records which outside services the site uses; later checks flag anything new.

AI agent activity

What it means: Drupal's AI agents, which can create fields, content types and configuration from plain-language instructions, were active around the same time something risky changed. For example, a dangerous permission was granted or configuration drifted. Most sites never see this finding. It needs the connector, and it appears only when Drupal's AI logging recorded agent activity.

It shows that two things happened together, not that the AI caused the change, and the finding always says so. Treat it as a reason to check:

Still stuck?

Contact us with the finding and what you've tried. We reply within one business day.