Cisco ISE needs no login, the Acronis cPanel flaw needs a foothold: one KEV deadline, two different risks

Two entries, one Saturday deadline

CISA's Known Exploited Vulnerabilities catalogue, version 2026.09.16, holds 1,713 entries, and the file carries a release stamp of 18:47:50 UTC on 16 September 2026. That is 2 hours 47 minutes after Cisco published its advisory for CVE-2026-76460 at 16:00 GMT, and 1 hour 24 minutes before the CVE record for that flaw was published at CVE.org. The same release added CVE-2026-87886, a flaw in the Acronis Backup plugin for cPanel & WHM and the Acronis Backup extension for Plesk. CISA's alert announced the pair together.

Both entries carry a federal due date of 19 September 2026. That is a Saturday. Both are flagged for forensic triage. Earlier the same day CISA had added a Google Pixel modem flaw, CVE-2026-58704, with the same due date; that one is covered in a separate briefing.

The matching dates invite you to treat the two as one job. They are not one job. The Cisco flaw needs nothing more than network reach to an API on the appliance that decides who and what gets onto your network. The Acronis flaw needs an attacker who is already a low-privileged user on a Linux hosting server. The fixes, the evidence you can collect, and the people who own each system are different.

What the record says, and who said it

The KEV entries are short. Most of what matters sits in the vendor advisories and in the enrichment data CISA attaches to CVE records, so the table below puts all of it in one place and names who assigned each value. Severity scores here were set by the vendors, not by CISA or NVD.

The two KEV entries side by side. Sources: CISA KEV JSON 2026.09.16, CVE.org and NVD APIs, Cisco and Acronis advisories, all fetched 17 September 2026.

Field	Cisco ISE (CVE-2026-76460)	Acronis Backup (CVE-2026-87886)
Weakness	CWE-648, incorrect use of privileged APIs	CWE-276, incorrect default permissions
Severity, and who set it	CVSS 3.1 base 10.0, assigned by Cisco	CVSS 3.0 base 7.8, assigned by Acronis
Attack vector	Network; no privileges; no user interaction	Local; low privileges; no user interaction
Vendor on exploitation	Cisco PSIRT is aware of active exploitation	Detected in limited, targeted attacks against cPanel & WHM deployments
KEV added and due	16 Sep 2026; due 19 Sep 2026	16 Sep 2026; due 19 Sep 2026
KEV forensic triage flag	Yes	Yes
KEV ransomware field	Unknown	Unknown
CISA enrichment (SSVC)	Exploitation active; automatable yes; technical impact total	None published; the CVE ID is still Reserved
NVD record	Received, not yet analysed	No record returned

The last two rows are the practical problem. CISA's implementation guidance says the agency "will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog". For CVE-2026-87886 there is nothing to attach that data to yet. At 07:39 UTC on 17 September the CVE Services API reported the ID as RESERVED with no published record, and the NVD API returned zero results. Any scanner, ticketing rule or dashboard that learns about vulnerabilities from NVD will not show this one, even though it is on the federal must-fix list with a three-day clock.

The Cisco record has the opposite shape: CISA's own enrichment, timestamped 20:40 UTC on 16 September, rates it automatable with total technical impact. That combination is what drives the shortest federal timeline regardless of whether the device is internet-facing, which is explained further down.

What the primary sources say and leave out, as of 17 September 2026. Secondary reporting is labelled.

Question	Stated	Not stated
Is it exploited?	Yes, by Cisco, by Acronis, and by CISA's listing	Scale, sectors, geography or start date for either flaw
Who is exploiting it?	Nothing, from any of the three	Any actor, campaign or motive
How was it found?	Cisco: during resolution of a TAC support case	Acronis: the advisory's credits and references fields are empty
Indicators of compromise?	Cisco: suspicious usernames in the API gateway access log	Acronis: none; CISA: no entry-specific triage steps in either KEV entry
Is Plesk exploited?	Acronis's Plesk update note: no signs of active exploitation	Whether that has changed since 15 September
How high does the Acronis escalation reach?	Local privilege escalation	Whether it reaches root, and from which account types
Ransomware use?	KEV field reads Unknown for both	Evidence either way

Cisco ISE: no login needed, root on the identity boundary

Identity Services Engine is Cisco's network access control platform. Cisco's product page describes it as putting identity at the centre of network control: it discovers and profiles what connects across wired, wireless, VPN and cloud environments, and applies the access and segmentation policy that decides what each connection may reach. ISE Passive Identity Connector (ISE-PIC) shares its release numbering in Cisco's fixed-release table. Cisco says both are affected regardless of device configuration.

The advisory is short on mechanism, which is normal for a bug that is being exploited. An API endpoint has insufficient authentication control; a crafted request to it gives unauthorised access that bypasses the web-based management interface. Cisco scores it 10.0 with scope changed. The sentence that matters most is tucked into the indicators section: after successful exploitation, "threat actors may obtain command execution with root privileges". Cisco adds that with that level of access, evidence of exploitation may be removed or hidden.

What the attacker needs first is network reach to the affected endpoint. No account, no stolen password, no user action. That is why the only mitigation Cisco offers is infrastructure access control lists that allow only required management and control plane traffic to the device. Cisco is explicit that this is a mitigation, not a workaround, and that it treats mitigations as temporary until a fixed release is installed. The advisory does not say which interface or port the vulnerable endpoint listens on, so an ACL is only as good as your knowledge of who can reach every ISE node today.

Cisco ISE and ISE-PIC first fixed releases. Sources: cisco-sa-ISE-ABP-VNSW7Tn5 and cisco-sa-hardening-ise-XU5EwX5T, both first published 16 September 2026.

Release train	First fixed release	Caveat stated by Cisco
3.0 and earlier	Migrate to a fixed release	End of Software Maintenance
3.1	3.1 Patch 12	Maintenance phase: only Critical SIR fixes included
3.2	3.2 Patch 11	Maintenance phase: only Critical SIR fixes included
3.3	3.3 Patch 12	None stated
3.4	3.4 Patch 7	Last supported ISE-PIC release
3.5	3.5 Patch 4	None stated

Two details in the records trip people up. First, the CVE record lists 30 ISE builds and two ISE-PIC builds as affected, starting at 3.1.0 Patch 8, with the default status set to unknown. That list is not a complete inventory of vulnerable builds; the fixed-release table is what to decide on. Second, for ISE-PIC owners Cisco's pages are not fully consistent: the CVE record lists ISE-PIC 3.5.0 as affected while the hardening advisory says ISE-PIC has reached end of sale with 3.4 as the last supported release. If you run ISE-PIC on 3.5, ask Cisco TAC which build to move to rather than guessing.

Cisco's check for attempted exploitation is to review the API gateway access log on every node for suspicious usernames. Its non-exhaustive example searches for one particular username:

admin# show logging application ise-kong/access.log | include dummyuser

Cisco says any output may indicate malicious activity, and that if compromise is suspected the nodes should be re-imaged and restored from configuration backup, not simply patched. Because an attacker with root can clean the box, Cisco also asks administrators to cross-check network and firewall logs outside the device for unexpected uploads from the ISE node to external addresses and downloads from malicious ones.

This is not the first time. The KEV catalogue already lists two Cisco ISE injection flaws, CVE-2025-20281 and CVE-2025-20337, both added on 28 July 2025 and both described by CISA as reachable through a specific API and ending in root. The new entry arrives 415 days later through the same kind of door: an API on the appliance, reached without credentials.

The same afternoon Cisco also published a separate ISE hardening release covering six further CVEs found in internal testing, which Cisco says used existing processes as well as frontier AI models. Their highest scores run from 6.5 to 10.0, and Cisco says it is not aware of malicious use of them. They share the fixed releases above, so one upgrade closes both advisories, with one exception: on the 3.1 and 3.2 trains Cisco includes only Critical SIR fixes, so those customers get the exploited fix without all of the hardening. Cisco groups the hardening findings under one CVE per weakness class, and its footnote places the exploited bug inside the improper access control class (CVE-2026-20192) while the exploited advisory tags it CWE-648. Cisco does not say whether the two CVE IDs describe overlapping code. If your scanner counts CVEs, do not read two IDs as two separate holes, or one ID as one.

Acronis: a local bug on a server where local can mean every customer

The Acronis Backup plugin for cPanel & WHM connects a web hosting server to Acronis's cloud backup service. Acronis's own installation guide (revision of 14 May 2026) has it installed from a root terminal. The installer registers a package repository for later updates, the plugin installs and registers a protection agent on the server, and the plugin lets the server administrator, and optionally resellers and hosting customers, browse and restore files, databases, mailboxes and whole accounts. From WHM, an administrator can revert the entire server to an earlier recovery point.

Acronis published advisory SEC-10986 at 15:30 UTC on 15 September. Its title is a local privilege escalation due to insecure file permissions. The CVSS 3.0 vector is AV:L/AC:L/PR:L/UI:N with high impact on confidentiality, integrity and availability, scored 7.8. The patched builds are 1.9.3.1021 for the cPanel & WHM plugin and 1.8.11.638 for the Plesk extension. The advisory's only narrative line says exploitation "has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments". The references and credits fields are empty.

The Acronis timeline from its own advisory database (timestamps UTC), with arithmetic by pk-sharma.com. Fetched 17 September 2026.

When	What Acronis published	What it says about exploitation
10 Sep, 13:30	Plesk extension 1.8.11 update (fixes one high severity flaw)	We see no signs of active exploitation
11 Sep, 12:30	cPanel & WHM plugin 1.9.3 HF3 update	Install immediately; exploitation detected in limited, targeted attacks
15 Sep, 15:30	Advisory SEC-10986 naming CVE-2026-87886; both update records marked updated	Exploitation detected against cPanel & WHM deployments
16 Sep	CISA adds CVE-2026-87886 to KEV, due 19 Sep	KEV entry covers both the cPanel plugin and the Plesk extension

So the fix for cPanel was public four days and three hours before the advisory named the flaw, and the Plesk fix five days and two hours before. Releasing a fix before the details is a common and defensible way to give customers a head start. The catch is that anyone who waits for a CVE, a scanner signature or a news story to trigger patching lost those days. The update records show a last-updated time identical to the advisory's publication, so they do not show whether the exploitation line was already there on 11 September.

How much evidence sits behind "limited, targeted"? BleepingComputer reports that Acronis said its assessment rests on a single report from a potentially affected customer. We could not find that statement on an Acronis page, so treat it as secondary reporting. It fits the advisory's cautious wording, and it also means the absence of wider reports tells you little about wider use.

What the attacker needs first is a low-privileged account on the server. On a dedicated server run by one company for its own sites, that is a real barrier: an attacker must already be inside. On a shared or reseller hosting server, the set of people with a low-privileged local account includes every hosting customer given shell, FTP or file access, and, as our inference rather than anything Acronis states, anyone who has compromised one of the hosted websites, because hosted web code commonly runs as that account's own user. Acronis does not say which account types can exploit the flaw, which files have the wrong permissions, or what privilege level the attacker ends up with.

CISA's catalogue shows why hosting plugins attract this kind of attack. In May 2026 it listed CVE-2026-48172 in the LiteSpeed cPanel plugin, a privilege escalation it described as usable by any cPanel user account to run scripts as root. In June it listed CVE-2026-54420 in the same plugin, a symlink-following flaw usable by a user with FTP or web shell access on shared hosting. That pattern does not prove the Acronis flaw works the same way. It does show that attackers go after privileged plugins on shared hosting boxes, and that CISA treats those local bugs as urgent.

Acronis's guide gives the update route as the system package manager. Checking the installed build first tells you whether you were exposed and for how long:

# RPM-based servers (AlmaLinux, CloudLinux, Rocky, RHEL, CentOS)
rpm -q acronis-backup-cpanel
yum update acronis-backup-cpanel

# DEB-based servers (Ubuntu)
dpkg -s acronis-backup-cpanel | grep Version
sudo apt update && sudo apt upgrade acronis-backup-cpanel

Acronis has published no indicators of compromise, no workaround and no mitigation for servers that cannot be updated at once. The KEV entry is equally bare: a link to the advisory and the directive. For a hosting provider that means the triage is generic Linux privilege-escalation hunting on every server that ran an older build, without assuming that exploitation started only after the fix appeared.

Where each flaw sits

The diagram lines the two flaws up step by step. Read it from the top: the first box is the precondition, and that is where the two entries part company.

What the three-day clock means, and what it does not

The due date comes from Binding Operational Directive 26-04, issued on 10 June 2026. It revoked BOD 22-01, the directive that created the KEV catalogue in 2021, and BOD 19-02. Instead of one fixed window for every KEV entry, it sets remediation timelines from four questions: is the asset publicly exposed, is the CVE in the KEV, can an adversary automate exploitation, and does exploitation give partial or total control?

In CISA's Table 1, "3 days and forensic triage" appears in exactly three of the 16 rows, and every one of them has total control: exposed and automatable, exposed and not automatable, or not exposed but automatable. Forensic triage means the agency must remediate within the three days and also assess whether the asset was already compromised.

For Cisco ISE the reading is simple: CISA's own enrichment says automatable and total, so the three days and the triage apply even to an ISE node that is not internet-facing. For Acronis there is no published enrichment. Our inference from Table 1 is that CISA treated the flaw as giving total control (the implementation guidance treats high confidentiality and integrity impact in CVSS as a sign of total control) and treated the asset as publicly exposed or the exploit as automatable. The attack vector is not one of the four questions. A hosting server is exposed to the internet whether or not the bug on it is reached locally, so the word local does not lengthen the federal clock.

CISA's guidance is also clear that the catalogue due date is its calculation from the data it has, and that the final determination of exposure is made by each agency, asset by asset. Even for a US federal agency, 19 September is a default, not a universal answer.

KEV due dates before and after BOD 26-04, counted by pk-sharma.com from the KEV JSON (version 2026.09.16) using dueDate minus dateAdded.

Entries added	Entries	Three-day due date	Any other due date
1 Jan to 9 Jun 2026	133	31	102 (2, 5, 14 or 21 days)
10 Jun to 16 Sep 2026	96	73 (76 per cent)	23 (all 14 days)

Since the directive took effect, three days has become the normal KEV deadline: 73 of the 96 entries added, and 55 of those 73 also carry the forensic triage flag. A three-day date on its own no longer marks an entry as unusually urgent. It is the precondition and the exposure that separate one entry from another.

For a UK organisation none of this is binding. BOD 26-04 applies to US federal civilian executive branch agencies, and CISA's alert says so while encouraging everyone else to prioritise KEV entries. The UK control most organisations are actually measured against is Cyber Essentials. Version 3.3 of the NCSC requirements, dated April 2026, says updates fixing vulnerabilities the vendor calls critical or high risk, or with a CVSS v3 base score of 7 or above, must be installed within 14 days of release. Both flaws qualify: Cisco scores 10.0, Acronis scores 7.8 and labels it high.

The clocks that actually apply, computed by pk-sharma.com from vendor release dates, the KEV entry and Cyber Essentials v3.3.

Clock	Cisco ISE	Acronis cPanel & WHM plugin
Fix released	16 Sep 2026	11 Sep 2026 (Plesk: 10 Sep)
Vendor states exploitation	16 Sep 2026	15 Sep 2026 at the latest
CISA federal due date	Sat 19 Sep 2026, with triage	Sat 19 Sep 2026, with triage
Cyber Essentials 14-day limit	30 Sep 2026	25 Sep 2026 (Plesk: 24 Sep)
Binding on a UK organisation?	Cyber Essentials, if certified and the node is in scope; contracts may add more	Cyber Essentials, if certified and the server is in scope; contracts may add more

The 14-day rule is the latest acceptable date for certification. The NCSC's own note says updates should be applied as soon as possible and calls 14 days a reasonable period, not an aspiration. For two flaws both vendors say were exploited before or at disclosure, the useful clock started before any of these dates. The honest reading of the federal deadline for a UK reader is as a signal of CISA's confidence in the exploitation evidence, plus a worked example of what a well-run response looks like: find it, collect evidence, fix it, and check whether you were already hit, inside three days.

Four comforting labels that are not controls

Local. A local privilege escalation sounds contained. It needs a foothold, and on shared hosting, footholds are what the platform sells to customers. The precondition is only reassuring if you know who holds local accounts on the server, and whether any hosted site has been compromised.

Limited, targeted. This describes what Acronis has seen, and according to secondary reporting that rests on one customer report. It is not a measure of your exposure, and it does not apply to whoever is not yet reporting.

Mitigation. Cisco's access control lists narrow who can reach the ISE API. Cisco itself calls mitigations temporary. An ACL written against yesterday's network diagram does not cover the jump host, the monitoring server or the partner VPN nobody remembered.

Backup. A backup plugin sounds like part of your recovery. On this server it is privileged software that can overwrite accounts and revert the whole machine. If the server was compromised, the plugin is part of what needs checking, and any restore should come from a recovery point you have reason to trust.

Method, motive, and what is not being alleged

Nothing in the sources attributes either campaign, and nothing here suggests either vendor was careless. Both did the core things right: fixed builds are available, exploitation was stated plainly, and Cisco published indicators and an honest note about what root access does to on-box evidence.

Commercial context is still worth keeping in view. Cisco's risk-based disclosure model, in effect since July 2026, groups bugs that share a weakness class under one umbrella CVE scored at the worst case in the group, and publishes on the first and third Wednesday of each month; 16 September was the third. Cisco frames the change around AI-driven vulnerability discovery, and says low-risk findings will no longer get individual advisories. It may well help customers patch; it also means CVE counts and CVSS scores no longer map one to one onto bugs, which matters for anyone reporting patch metrics upwards. Acronis sells backup and cyber protection, and its advisory is terse: no credits, no references, no indicators. Releasing the fix days before the advisory is standard practice, not a cover-up, but it does move the burden of noticing onto customers.

The reading of CISA's Table 1 for the Acronis entry is our inference from the published directive, because CISA has not published the enrichment values behind it. The claim that hosted web code commonly runs as the account's own user is general hosting practice, not a statement from Acronis about this flaw.

What to do, in order

The question that exposes the gap

The catalogue entry tells you that CISA has evidence of exploitation and that US federal agencies have until Saturday. It cannot tell you whether the low-privileged account on your hosting server belongs to a customer, a compromised website or an attacker. Nor can it tell you whether your ISE API was reachable from somewhere it should not have been in the weeks before Cisco published.

So the question for the review after the weekend is not whether the patches went on by 19 September. It is this: who could reach these two systems before the fixes existed, and what evidence do we still hold that proves they did not?

Key facts