/ Security  ·  September 18, 2026  ·  20 min read

The backup plugin on your web host is being exploited, and on one of the three affected control panels the update installs the vulnerable version

CVE-2026-87886 is a privilege escalation flaw in the Acronis Backup integrations that web hosts bolt onto cPanel, Plesk and DirectAdmin. Acronis confirmed exploitation in the wild in limited, targeted attacks and CISA added it to the Known Exploited Vulnerabilities catalog on September 16 with a three-day federal deadline and a forensic triage requirement. We checked the vendor's own distribution channels rather than the coverage, and found four things nobody has reported. First, the headline: DirectAdmin is named as affected in the CVE record Acronis itself published, the fix is build 1.2.3.238, and the official DirectAdmin update channel is still serving 1.2.3.224 as of this morning, with a Last-Modified date of October 2025. The plugin's own version check points at that same file, so DirectAdmin's Plugin Manager reports you are up to date. Second, CISA's KEV entry names only cPanel and Plesk, so DirectAdmin operators get no signal from either direction. Third, the fixed cPanel package was sitting in the public yum and apt repositories on September 10, six days before KEV and seven before the CVE record existed. Fourth, the whole thing published backwards: KEV first, vendor advisory second, CVE record third. Plus why low-privileged local access is not a high bar on a shared host, what CISA's own structured assessment actually says, and the four questions to send your hosting provider today. Updated September 19: we re-ran the check and the DirectAdmin channel moved, but only halfway. The version endpoint now advertises the fixed build 1.2.3.238 on both hostnames, while the tarball behind it is byte-for-byte the October 2025 file and still contains version=1.2.3.224. DirectAdmin's Plugin Manager will now show an update available, download it, and install the vulnerable build over itself while reporting success, which is a worse failure than yesterday's silence. The one command that tells you the truth is in the article.

By Rushil Shah
SecuritySmall BusinessWeb Development

There is a piece of software on the server hosting a great many small business websites that the business has never heard of, did not choose, cannot see, and cannot patch. It is the backup integration the hosting company installed into the control panel. It exists so that a customer can click Restore and get yesterday’s site back, which is a genuinely good thing that has saved a lot of people a lot of money.

To do that job it has to be able to read and write every account on the machine. Which is a polite way of saying it is root.

On September 16, CISA put a flaw in one of these things on the list of vulnerabilities it has confirmed are being exploited right now.

Everything below was checked against primary sources on September 18, 2026, and where a claim is about the current state of a download server, we checked it this morning and said so. Sources are CISA’s Known Exploited Vulnerabilities JSON feed pulled directly, the CVE record from MITRE’s CVE Services API, the NVD record from the NVD API, Acronis’s own advisory database through its JSON API, and the actual package repositories and download endpoints that the three control panel plugins install from. The version comparisons in the middle of this article are ours, and the commands are included so you can repeat them.

What happened

CVE-2026-87886 is a local privilege escalation flaw caused by insecure file permissions in the Acronis Backup integrations for three hosting control panels. Acronis is the CNA for its own products, so the CVE record is the vendor’s record. In its exact words:

Local privilege escalation due to insecure file permissions. The following products are affected: Acronis Backup plugin for cPanel & WHM (Linux) before build 1.9.3.1021, Acronis Backup extension for Plesk (Linux) before build 1.8.11.638, Acronis Backup plugin for DirectAdmin (Linux) before build 1.2.3.238.

Acronis scores it 7.8 High with the vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. NVD has published the record but lists its status as Undergoing Analysis, so there is no NVD primary score, only Acronis’s. The weakness class is CWE-276, Incorrect Default Permissions.

Acronis’s advisory, SEC-10986, says this about exploitation:

Exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments.

CISA added it to the Known Exploited Vulnerabilities catalog on September 16, 2026, in catalog version 2026.09.16. We pulled the feed rather than reading about it. The entry carries a remediation deadline of September 19, three days, and forensicTriage set to Yes, which under BOD 26-04 means federal agencies are told to collect evidence rather than simply patch and move on. That flag is not common. There are 1,713 entries in the catalog and 55 of them carry it, all added since July 1 this year.

CISA’s own structured assessment of the flaw, added to the CVE record on September 18 through its Vulnrichment programme, reads:

Signal Value
Exploitation active
Automatable no
Technical Impact total

Hold onto that middle row. It is the difference between this and the stories we have been writing all month.

The finding: one of the three control panels cannot get the fix

Here is the part that sent us looking at download servers instead of news articles.

The CVE record names three products. CISA’s KEV entry names two. The catalog’s description of the vulnerability reads, verbatim:

Acronis Backup plugin for cPanel & WHM and extension for Plesk contains an incorrect default permissions vulnerability that could allow for privilege escalation.

DirectAdmin is missing. So is it missing from essentially every piece of coverage we read, which followed the advisory’s exploitation sentence and wrote about cPanel.

That would be a footnote if the DirectAdmin fix were a click away. It is not.

The DirectAdmin plugin is not distributed as a signed package from a repository, the way the cPanel one is. It is a tarball. Acronis’s own installer script, still the documented install route, fetches it like this:

LATEST_BUILD_BASE="https://download.acronis.com/ci/directadmin/stable/acronis-directadmin-stable/acronisbackup.tar.gz"
ACRONIS_BACKUP_FOLDER="/usr/local/directadmin/plugins/acronisbackup"

Inside that tarball is a plugin.conf that tells DirectAdmin’s Plugin Manager where to look for updates:

name=Acronis Backup
version=1.2.3.224
update_url=https://dl.acronis.com/u/ci/directadmin/stable/acronis-directadmin-stable/acronisbackup.tar.gz
version_url=https://dl.acronis.com/u/ci/directadmin/stable/acronis-directadmin-stable/version.html

The fix is build 1.2.3.238. The stable channel is serving 1.2.3.224.

We did not want to be wrong about this, so we checked it repeatedly, with cache-busting query strings, across both hostnames Acronis uses:

curl -s "https://dl.acronis.com/u/ci/directadmin/stable/acronis-directadmin-stable/version.html"
# 1.2.3.224

curl -s "https://download.acronis.com/ci/directadmin/stable/acronis-directadmin-stable/version.html"
# 1.2.3.224

Four requests, two hosts, same answer. Then we looked at the tarball itself:

curl -sI "https://dl.acronis.com/u/ci/directadmin/stable/acronis-directadmin-stable/acronisbackup.tar.gz"
# Last-Modified: Thu, 16 Oct 2025 12:20:34 GMT

The file that the DirectAdmin stable channel hands out has not been touched since October 2025. We downloaded it and read the version out of the extracted plugin.conf to be certain the version.html file was not simply stale: 1.2.3.224, matching. There is no beta or dev channel to fall back to; stable is the only one that resolves.

So on a DirectAdmin server this morning, the sequence is:

  1. The CVE record says you are affected below build 1.2.3.238.
  2. CISA’s KEV entry does not mention your control panel, so nothing in your feed reader flags you.
  3. Your Plugin Manager checks version_url, sees 1.2.3.224, compares it to the 1.2.3.224 you have installed, and tells you there is no update available.
  4. There is an update. It is just not there.

The two other panels are fine, and we confirmed that too rather than assuming it. The cPanel apt and yum repositories both serve the fixed build:

curl -s "https://dl.acronis.com/u/ci/cpanel/stable/deb/Packages"
# Package: acronis-backup-cpanel
# Version: 1.9.3.1021

The RPM metadata reports acronis-backup-cpanel 1.9.3-1021.el7, and the Plesk extension catalogue lists 1.8.11-638. Both are at or past the patched build. Only DirectAdmin is stuck.

One piece of honest context, because it changes how urgent this is without changing that it is a gap. Acronis publishes a separate update page per product, and the three do not say the same thing. The cPanel page says the update “should be installed immediately by all users” and that exploitation has been detected in the wild. The Plesk and DirectAdmin pages both say it “is recommended for all users” and, in Acronis’s words, “We see no signs of active exploitation of the vulnerabilities listed on this page.” So the attacks Acronis has seen are against cPanel deployments, and DirectAdmin operators are not currently the ones being hit. They are simply the ones who, if that changes, have nowhere to go.

Update, September 19, 2026: the version file moved. The tarball did not.

We said to re-run the curl rather than trust the paragraph, so we re-ran it this morning. The version endpoint has changed, and the change makes things worse rather than better.

As of 13:10 UTC on September 19, both hostnames now report the patched build:

curl -s "https://dl.acronis.com/u/ci/directadmin/stable/acronis-directadmin-stable/version.html"
# 1.2.3.238

curl -sL "https://download.acronis.com/ci/directadmin/stable/acronis-directadmin-stable/version.html"
# 1.2.3.238

That is the fixed build number, and if you stopped there you would conclude the gap has closed. It has not. The file that DirectAdmin’s Plugin Manager actually downloads, the one named in the plugin’s own update_url, is unchanged:

curl -sI "https://dl.acronis.com/u/ci/directadmin/stable/acronis-directadmin-stable/acronisbackup.tar.gz"
# Last-Modified: Thu, 16 Oct 2025 12:20:34 GMT
# Content-Length: 34063604
# ETag: "ded06eae0de153214d34149da79e2a54:1760617255.991167"

That is the same Last-Modified header we recorded yesterday, and the ETag’s trailing timestamp, 1760617255, is October 16, 2025 as well. We downloaded the tarball with a cache-busting query string, extracted it, and read the manifest that ships inside it:

tar xzf acronisbackup.tar.gz && grep ^version plugin.conf
# version=1.2.3.224

So the advertised version is 1.2.3.238 and the payload behind it is still 1.2.3.224. We checked the version endpoint four times across both hostnames, all four returned 1.2.3.238, and the SHA-256 of the downloaded archive is c4d41ab9107110312930e8b729825138e782974d9c596b8413b99bb36629d7bd.

Yesterday, a DirectAdmin operator’s Plugin Manager reported no update available, and that was wrong but at least it was quiet. Today it will report that an update is available, because it compares the installed 1.2.3.224 against the advertised 1.2.3.238. Clicking update fetches that tarball and installs 1.2.3.224 over 1.2.3.224. The operation succeeds, the plugin is unchanged, and depending on how the installed version is recorded, the Plugin Manager may well offer the same update again tomorrow.

An update that appears to fail is annoying. An update that appears to succeed and changes nothing is considerably worse, because it converts an open question into a closed one in the operator’s head and in any report they hand to a client. If you run DirectAdmin, the check that actually settles it is the last command above, run against the installed plugin rather than the download:

grep ^version /usr/local/directadmin/plugins/acronisbackup/plugin.conf
# 1.2.3.238 means you genuinely have the fix
# 1.2.3.224 means you do not, whatever the Plugin Manager says

The second finding: the fix was public a week before anyone was told to install it

We read the build timestamp out of the cPanel repository metadata. The fixed package was built at 09:13:36 UTC on September 10, 2026, and the repository index was regenerated twelve seconds later.

Set that against the rest of the timeline, all of which comes from machine-readable fields rather than press dates:

When (UTC) What Source
Sep 10, 09:13 Fixed cPanel package built and published to the stable yum and apt repos repo metadata
Sep 10, 13:30 Plesk 1.8.11 update page published Acronis advisory API
Sep 11, 12:30 cPanel 1.9.3 HF3 update page published, “install immediately”, exploitation in the wild Acronis advisory API
Sep 15, 15:30 Both the cPanel and Plesk update pages revised Acronis advisory API
Sep 16, 18:47 CISA publishes KEV catalog 2026.09.16 containing CVE-2026-87886, due Sep 19 KEV feed
Sep 17, 13:30 Advisory SEC-10986 published, and the DirectAdmin update page with it Acronis advisory API
Sep 17, 22:57 CVE record published by Acronis as CNA MITRE CVE API
Sep 17, 23:19 NVD publishes NVD API
Sep 18, 12:28 CISA Vulnrichment adds the SSVC assessment above MITRE CVE API

Two things fall out of that table.

The fix reached the update channel six days before KEV and seven before the CVE existed publicly. Any host running unattended upgrades on that repository was patched on September 10 and never knew there was anything to worry about. Any host that patches when a CVE appears in a feed was exposed for a week, while the fix sat on a public server, for the entirely rational reason that nothing had told them to install it.

The publication order ran backwards. The normal sequence is CVE record, then advisory, then, if things go badly, KEV. Here it was KEV, then advisory, then CVE record, with about twenty-eight hours between CISA confirming exploitation and the CVE record existing at all. For roughly a day, the only machine-readable public statement that this flaw existed was CISA’s, and it named two of the three affected products.

We are not reading malice into that. Acronis published a fix first and held technical detail back, which is defensible and which BleepingComputer reported was deliberate, to give administrators time to patch. The point is narrower and it is operational: if your patching process keys off CVE feeds, this one was invisible for a week after the fix existed, and if it keys off KEV, it named two thirds of the affected products.

Why “local” and “low privilege” are not the reassurance they sound like

The CVSS vector says AV:L and PR:L. Attack vector local, privileges required low. Read plainly, that says an attacker needs to already be on the machine with an ordinary account. On a server in your office, that is a real barrier.

On shared hosting it is not a barrier at all. It is the product.

On a cPanel or Plesk or DirectAdmin box, every hosting customer on that machine has a Linux user account. That is what the account is. And on cPanel specifically, PHP runs as the account’s own user through suEXEC or a per-user PHP-FPM pool, which is the isolation model that keeps one customer out of another customer’s files. It works well, and it has an unavoidable consequence: any code that runs on any website on that server is already an authenticated low-privileged local user.

So the precondition for this flaw is satisfied by any one of the following, none of which involve the attacker knowing your hosting password:

  • A neighbour on the same shared server who signed up with a stolen card.
  • An out-of-date WordPress plugin on somebody else’s site on the same box.
  • A compromised site of your own, which is the case we wrote about in the WordPress core pre-auth RCE post, where an unauthenticated attacker gets code execution as the site’s user and then needs exactly this kind of flaw to go further.

That is what CISA’s Automatable: no is telling you, and it is worth reading correctly rather than as reassurance. It means nobody is going to mass-scan the internet and wake up owning ten thousand servers, the way they did with the Vite dev servers we wrote about on Wednesday. It also means this is not a first-stage tool. It is a second-stage tool. It is the thing that converts “someone got into one badly maintained website” into “someone owns the server, every site on it, and the backup agent.”

And the backup agent is the part that should make a business owner sit up. The whole value of an off-machine backup is that it survives the machine being compromised. A privilege escalation into a root-level backup integration is a route to the credentials and the console that manage those backups. We have no evidence that is what the observed attacks did, and we are not going to claim it. But it is the reason this particular 7.8 deserves more attention than most 7.8s.

What the catalogue says about this class of flaw

We counted, because the shape of the catalogue is more informative than any single entry.

CWE-276 is almost unheard of in KEV. Across all 1,713 entries in the catalogue, going back to its creation, exactly five are classified as Incorrect Default Permissions:

CVE Vendor Product Added
CVE-2026-87886 Acronis Backup 2026-09-16
CVE-2024-55956 Cleo Multiple Products 2024-12-17
CVE-2024-51378 CyberPersons CyberPanel 2024-12-04
CVE-2024-51567 CyberPersons CyberPanel 2024-11-07
CVE-2022-22948 VMware vCenter Server 2024-07-17

Three of those five are hosting control panel software. That is a very small sample and we are not going to build a theory on it, but it is a striking coincidence for a category that most security coverage ignores entirely.

Backup products are similarly rare, and this one is a new shape. Nine KEV entries in total name a backup product: this one, plus Veeam Backup & Replication four times, Veritas Backup Exec Agent three times, and NAKIVO once. Every one of the previous eight is an enterprise backup server, reachable over the network, exploited remotely. This is the first that is a plugin bolted into a shared hosting control panel and exploited from a local account. Different product, different attacker position, same underlying observation: the software that can restore everything can also take everything.

How to check, in about two minutes

If you run the server (you have WHM root, a Plesk admin login, or DirectAdmin admin):

# cPanel & WHM, RHEL-family
rpm -q acronis-backup-cpanel
# want 1.9.3-1021 or later

# cPanel & WHM, Ubuntu
dpkg -l acronis-backup-cpanel
# want 1.9.3.1021 or later

# Plesk
plesk bin extension --list | grep -i acronis
# want 1.8.11-638 or later

# DirectAdmin
cat /usr/local/directadmin/plugins/acronisbackup/plugin.conf | grep ^version
# want 1.2.3.238 or later

On cPanel the update is an ordinary package upgrade, yum update acronis-backup-cpanel or apt-get install --only-upgrade acronis-backup-cpanel, and the fixed build is already in the repository you are configured for. On Plesk, update the Acronis Backup extension from the extensions catalogue. On DirectAdmin, as of this morning, there is nothing to install, and the honest advice is to open a ticket with Acronis asking when build 1.2.3.238 reaches the stable channel, and in the meantime to treat every account on that server as a potential starting point rather than assuming the isolation holds.

If you are not running the plugin at all, you are not affected by this CVE. Checking takes ten seconds and is worth doing before anything else.

If you are a small business on somebody else’s hosting, which is most people reading this, you cannot run any of those commands and you should not try. Send your host four questions instead. They are short, they are answerable, and a competent host will answer all four inside a day:

  1. Do you run the Acronis Backup plugin or extension on the server my sites are on, and if so, on which control panel?
  2. If it is cPanel or Plesk, what build is installed, and is it at or past 1.9.3.1021 or 1.8.11-638 respectively?
  3. If it is DirectAdmin, build 1.2.3.238 is the fix and it is not currently available from Acronis’s stable channel. What is your plan while that is true?
  4. CISA flagged this one for forensic triage rather than patching alone. Have you reviewed the server for signs of privilege escalation since September 10, and if so, what did you look at?

Question four is the one that separates a host that is paying attention from a host that ran an update and stopped. You are entitled to an answer to it. If the reply is a form letter about taking security seriously, that is also an answer.

What we could not verify

  • The technical mechanism of the flaw. Acronis has deliberately not published which files carry the wrong permissions or how the escalation is achieved. We did not reverse-engineer the packages to find out, and we would not publish it if we had. Everything above about exploitability is reasoning from the CVSS vector, the CWE class and the vendor’s own description.
  • Who is exploiting it, at what scale, and to what end. Acronis says limited and targeted, based on a report from an affected customer. There is no named victim, no attribution and no published indicator of compromise in any source we read.
  • Whether the attacks reached the backup data or the Acronis Cloud console. We have seen nothing that says they did. The concern in this article is structural, not reported.
  • How many servers run these plugins. We found no figure from a source we could pull directly and we are not repeating one from coverage.
  • Whether build 1.2.3.238 exists anywhere at all. Acronis’s advisory names it as the fixed DirectAdmin build and has published an update page for it. We could not find it on any channel we could reach, and we cannot tell from outside whether it is built and not yet pushed, pushed to a partner-only channel, or still in progress.
  • Whether the DirectAdmin channel has moved since we checked. It has, partly. Our last check was 13:10 UTC on September 19, 2026: the version endpoint now advertises 1.2.3.238 and the tarball it points at still contains 1.2.3.224. See the September 19 update above. If you are reading this later still, run the commands there rather than trusting this paragraph.
  • Why the two moved apart. A version file updated ahead of the artefact it describes is the ordinary signature of a staged release where one step has not completed, but we cannot see Acronis’s release process and we are not going to guess at intent. What we can see is the effect on the Plugin Manager, and that is what the update above describes.

The short version

Most of the security writing this month, ours included, has been about things you can go and fix: upgrade Vite, patch GitLab, restart Chrome. This one is different in a way that is worth naming, because it is the more common situation and it gets written about less.

The vulnerable software is on a machine you rent a slice of. You did not install it, you cannot see it, you cannot patch it, and the flaw is only reachable by someone who already has a foothold on that machine, which on shared hosting is a much lower bar than the CVSS vector makes it sound. The only lever you have is the question you send your host, and the only real decision is what you do if the answer is unconvincing.

For the specific case: if your site is on cPanel or Plesk, the fix exists and has existed since September 10, so this is a question of whether your host applied it. If your site is on DirectAdmin, the fix is named in the CVE, absent from CISA’s description, and, as of this morning, not available from the channel the plugin itself checks. That combination is worth an email today.

If you want help working out which of those three you are actually on, or a second pair of eyes on the answer your host sends back, get in touch. We are in Toronto, we ask these questions on behalf of clients regularly, and the version of this conversation that happens before an incident is considerably shorter than the one that happens after.

Sources

  • Known Exploited Vulnerabilities Catalog JSON feed, CISA, downloaded September 18, 2026 at catalog version 2026.09.16, for the full CVE-2026-87886 entry including its quoted short description naming only cPanel & WHM and Plesk, the September 16 date added, the September 19 due date, the forensicTriage value of Yes and the CWE-276 classification, and for the total of 1,713 entries, the 229 added during 2026, the 55 entries carrying the forensic triage flag, the five CWE-276 entries and the nine entries naming a backup product. The counts and both tables built from them are our own analysis of that file.
  • CISA Adds Two Known Exploited Vulnerabilities to Catalog, CISA, September 16, 2026, for the alert naming CVE-2026-87886 and CVE-2026-76460 and its reference to BOD 26-04
  • CVE-2026-87886 record, retrieved from the MITRE CVE Services API on September 18, 2026, for the quoted description naming all three affected products and their fixed builds, the Acronis CNA attribution, the CVSS 3.0 score of 7.8 and its vector, the CWE-276 problem type, the reserved date of September 9 and the published date of September 17 at 22:57 UTC, and the CISA-ADP Vulnrichment SSVC assessment of Exploitation active, Automatable no and Technical Impact total, timestamped September 18 at 12:27 UTC
  • NVD record for CVE-2026-87886, queried through the NVD API on September 18, 2026, for the published timestamp of September 17 at 23:18 UTC, the vulnerability status of Undergoing Analysis, the absence of an NVD primary CVSS score, and the CISA action due date of September 19
  • Acronis advisory SEC-10986, retrieved through the Acronis advisory JSON API on September 18, 2026, for the quoted exploitation statement, the three affected products with patched builds 1.9.3.1021, 1.8.11.638 and 1.2.3.238, the CVSS score and vector, and the advisory publication timestamp of September 17 at 13:30 UTC
  • Acronis update records UPD-2609-3d72-20a7 for cPanel & WHM 1.9.3 HF3, UPD-2609-efb0-50b2 for Plesk 1.8.11 and UPD-2609-6ade-5b2e for DirectAdmin 1.2.3, retrieved through the same API on September 18, 2026, for their publication timestamps of September 11, September 10 and September 17 respectively, the September 15 revision of the first two, the quoted “should be installed immediately by all users” on the cPanel record and the quoted “We see no signs of active exploitation of the vulnerabilities listed on this page” on the other two
  • Acronis distribution endpoints, all retrieved September 18, 2026: the cPanel installer script and the acronis-backup-cpanel package indexes at dl.acronis.com/u/ci/cpanel/stable/deb/Packages and dl.acronis.com/u/ci/cpanel/stable/rpm/repodata/, for the published version 1.9.3.1021, the RPM release string 1.9.3-1021.el7 and the package build timestamp of September 10, 2026 at 09:13:36 UTC; and the DirectAdmin installer script, the DirectAdmin version.html endpoint on both dl.acronis.com and download.acronis.com, and the DirectAdmin plugin tarball itself, for the published version 1.2.3.224, the matching version=1.2.3.224 and version_url lines in the extracted plugin.conf, and the Last-Modified header of Thu, 16 Oct 2025 12:20:34 GMT. The version comparison and the conclusion that the DirectAdmin fix is not available on that channel are our own testing.
  • Acronis Backup extension in the Plesk extensions catalogue, retrieved September 18, 2026, showing version 1.8.11-638
  • Acronis warns of actively exploited flaw in its cPanel backup plugin, BleepingComputer, and Acronis cPanel Backup Plugin Vulnerability Exploited in Targeted Attacks, The Hacker News, both September 16, 2026, for Acronis basing its exploitation assessment on a report from a potentially affected customer and for its decision to withhold technical detail while administrators patch. Both are also cited for the state of the coverage: neither mentions DirectAdmin.
  • Acronis DirectAdmin distribution endpoints, re-checked September 19, 2026 at 13:10 UTC, for the September 19 update: the version.html endpoint on both dl.acronis.com and download.acronis.com returning 1.2.3.238 across four cache-busted requests, the acronisbackup.tar.gz response headers still carrying Last-Modified: Thu, 16 Oct 2025 12:20:34 GMT, Content-Length: 34063604 and an ETag whose trailing timestamp resolves to the same October 2025 date, and the version=1.2.3.224 line in the plugin.conf extracted from that downloaded archive, SHA-256 c4d41ab9107110312930e8b729825138e782974d9c596b8413b99bb36629d7bd. The conclusion that the Plugin Manager will now offer and apply a no-op update is our own analysis of the plugin’s documented update_url and version_url behaviour.
  • Three Linux kernel flaws on CISA’s exploited list, our September 19 write-up, for the recount of the catalog at version 2026.09.18: 1,716 entries and 58 carrying the forensic triage flag, against the 1,713 and 55 recorded above at 2026.09.16. The five CWE-276 entries and the nine entries naming a backup product both reproduce unchanged at the newer catalog version.
  • BOD 26-04: Prioritizing Security Updates Based on Risk, CISA, for the risk-based deadline framework and the forensic triage requirement referenced in the KEV entry
● Taking new projects

Have something that needs shipping?

One call. Thirty minutes. You leave with an honest read on scope, timeline, and price, whether we're the right fit or not.