The KEV entry says path traversal. Its own CWE, and both sources it cites, say JWT signature bypass

One record, two different vulnerabilities

On 24 September 2026 at 19:00 UTC, CISA published catalogue version 2026.09.24 of the Known Exploited Vulnerabilities list, taking it to 1,723 entries. Two flaws were added, both with a remediation deadline of 27 September, three days later.

One of the two records disagrees with itself. The entry for CVE-2026-5430 is named "WSO2 Multiple Products Path Traversal Vulnerability" and its description says the products "contain a path traversal vulnerability that could allow for unrestricted file upload and lead to remote code execution". The CWE recorded in the same entry is CWE-347, Improper Verification of Cryptographic Signature. The two pages the entry links to, WSO2's own advisory and the NVD record, both describe an authentication bypass: a JSON Web Token signed with an algorithm the server does not support is accepted anyway.

Neither linked source mentions path traversal. Neither mentions file upload.

What that does not establish. It does not establish that the entry should be ignored, because the CVE, the vendor, the affected products and the deadline are all correct and the flaw is genuinely being exploited. It does not establish that WSO2 products have no path traversal issue anywhere, only that this CVE is not one. It does not establish how the error was made, because CISA has not said and this briefing has not asked. And it does not establish that the catalogue is unreliable in general: the other entry added the same day is internally consistent, which is the comparison that makes this one visible.

What it does establish is that a defender who triages from the catalogue's own words, which is what the catalogue is for, will go looking for the wrong thing in the wrong place.

The record, field by field

These are the values as published in the catalogue JSON, fetched on 25 September 2026.

The KEV record for CVE-2026-5430, catalogue version 2026.09.24

Field	Value
vendorProject	WSO2
product	Multiple Products
vulnerabilityName	WSO2 Multiple Products Path Traversal Vulnerability
shortDescription	Contains a path traversal vulnerability that could allow for unrestricted file upload and lead to remote code execution
cwes	CWE-347, Improper Verification of Cryptographic Signature
dateAdded	2026-09-24
dueDate	2026-09-27
knownRansomwareCampaignUse	Unknown
forensicTriage	Yes
notes	Links to the WSO2 advisory and the NVD record

Read the third and fourth rows against the fifth. A path traversal that leads to unrestricted file upload is CWE-22 territory, or CWE-434 for the upload. CWE-347 is the failure to verify a cryptographic signature properly. They are not adjacent categories. They are different bugs, in different parts of a product, found by different tests and fixed by different people.

The machine readable field is right. The two human written fields are wrong. That ordering matters, because most tooling ingests the JSON and most humans read the name.

What the linked sources say

WSO2 published advisory WSO2-2026-5328 on 3 May 2026, version 1.0.0, severity Critical. Its overview is "Account takeover via authentication bypass vulnerability". Its description is one sentence: "JWT authentication can be bypassed when a token is signed using an unsupported algorithm, allowing unauthorized access." Its impact statement is that exploitation "may lead to unauthorized access, including potential compromise of administrative accounts and full account takeover".

The NVD record, published 6 August 2026, says the same thing at slightly greater length: "The JWT authentication mechanism accepts tokens signed with algorithms other than those explicitly configured or supported. This allows an attacker to craft a JWT with an unsupported algorithm, which is then incorrectly validated, leading to unauthorized access."

The CVSS on the record is 10.0, assigned by WSO2 as the CNA, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The scope change is what takes it to ten. WSO2 itself notes the score drops to 9.8 in single tenant deployments, where the impact is contained within one security boundary. NVD has published no score of its own.

The same CVE as described by each source

Source	What it says the flaw is
KEV name and description	Path traversal leading to unrestricted file upload and remote code execution
KEV cwes field	CWE-347, improper verification of a cryptographic signature
WSO2 advisory WSO2-2026-5328	JWT authentication bypassed when a token is signed with an unsupported algorithm
NVD record for CVE-2026-5430	Tokens signed with algorithms other than those configured are incorrectly validated

Affected products, from the vendor: API Control Plane 4.5.0 and 4.6.0, API Manager 4.1.0 through 4.6.0, Traffic Manager 4.5.0 and 4.6.0, Universal Gateway 4.5.0 and 4.6.0. Community users fix it through two public pull requests, in carbon-apimgt and product-apim. Subscription holders take an update level, which varies by product and version. WSO2 credits the Hacktron Team and, in the advisory, states no exploitation.

Why the label sends you to the wrong place

The two descriptions do not just differ academically. They imply different hunts.

Take the catalogue's wording at face value and you are looking for a traversal: a request containing dot dot slash sequences, a file written outside the directory it should have landed in, a web shell in an upload folder, a web server log full of odd paths. You would check whether the product exposes an upload endpoint at all. You would probably ask your web application firewall vendor whether their traversal rules cover it.

The actual flaw leaves none of those traces. A token is presented, the gateway looks at the algorithm named in its header, and instead of rejecting an algorithm it was never configured to accept, it validates the token anyway. The request that follows looks entirely legitimate, because it is a correctly formed authenticated call. There is no traversal, no upload and no malformed path. There is a session, and potentially an administrative one.

That is the friendly name fallacy pointed at the one artefact the whole industry has agreed to treat as authoritative. "Path traversal" is a comforting label because everyone knows what to do about it. Doing those things here would produce a clean report and an open door.

The other entry added the same day

CVE-2026-71362, Adobe Commerce and Magento, went into the catalogue in the same release with the same three day deadline. Everything about it agrees. The KEV name calls it an incorrect authorization vulnerability. The CWE is CWE-863, Incorrect Authorization. Adobe's own bulletin, APSB26-92, lists it as Incorrect Authorization with a privilege escalation impact, Critical, CVSS 9.1, no authentication required and no admin privileges required.

That consistency is the control in this experiment. The same team, the same release, the same process, one record right and one wrong.

The two additions of 24 September 2026, compared

Field	CVE-2026-5430, WSO2	CVE-2026-71362, Adobe
KEV name	Path traversal	Incorrect authorization
KEV CWE	CWE-347, signature verification	CWE-863, incorrect authorization
Vendor advisory says	JWT authentication bypass	Incorrect authorization, privilege escalation
Name matches the vendor	No	Yes
CVSS and who assigned it	10.0, WSO2 as CNA	9.1, Adobe as CNA
Vendor advisory published	3 May 2026	11 August 2026
Days to the KEV entry	144	44
Deadline once catalogued	3 days	3 days

The Adobe entry carries its own quieter lesson. APSB26-92 shipped on 11 August with a priority rating of 2, which is Adobe's thirty day tier, and the bulletin states plainly: "Adobe is not aware of any exploits in the wild for any of the issues addressed in these updates." Forty four days later the same flaw carries a federal deadline of three days. Nothing about the vulnerability changed in between. What changed is that somebody used it.

A vendor priority rating describes the vendor's view of risk on the day of publication. It is not a forecast, and it ages badly.

The clock on both of them

Both entries fall under Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, which CISA's alert says "requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures listed in CISA's KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation". Both are flagged forensicTriage: Yes, which pulls in CISA's forensic triage requirements rather than just a patch.

The WSO2 timeline is the longer one. The advisory is dated 3 May. NVD published on 6 August, 95 days later. The catalogue entry landed on 24 September, 144 days after the advisory and 49 days after NVD. The deadline is 3 days.

That shape is now normal rather than exceptional. With this release, September 2026 stands at 36 additions to the catalogue, and 28 of them carry a three day deadline rather than fourteen. A patch that has been available since the spring becomes a three day emergency the week somebody starts using it.

What to do about it

The question this leaves

There is no scandal here and no negligence worth alleging. Somebody wrote a sentence for a record under time pressure, during a week in which the catalogue took 36 additions, and the sentence was wrong while the structured field beside it was right. It will probably be fixed. The Adobe entry in the same release shows the process works most of the time.

The uncomfortable part is what it reveals about the rest of the pipeline. Between CISA's record and the engineer who patches a gateway sit a vulnerability management platform, a ticketing system, a dashboard and a summary written by somebody who did not read the advisory. Every one of those hops prefers the short human sentence to the linked primary source, because the short sentence fits in a column. The one field that was correct here, cwes, is the field most likely to have been dropped along the way.

So the question is not whether CISA made a mistake. It is this: if the name in the catalogue had been wrong about something your team owns, at what point in your own pipeline would anybody have noticed?