The catalogue calls it path traversal. Its own CWE, and both sources it cites, say authentication bypass

One record, two descriptions of different things

CISA added CVE-2026-5430, affecting several WSO2 products, to the Known Exploited Vulnerabilities catalogue on 24 September 2026, with a deadline of 27 September. Three days.

Here is what the record says about itself, quoted from the catalogue JSON:

• vulnerabilityName: "WSO2 Multiple Products Path Traversal Vulnerability"
• shortDescription: "contain a path traversal vulnerability that could allow for unrestricted file upload and lead to remote code execution"
• cwes: ["CWE-347"]

CWE-347 is Improper Verification of Cryptographic Signature. It is not path traversal, which is CWE-22, and it is not unrestricted file upload, which is CWE-434.

Now the two sources the same record links to in its notes field. WSO2's own advisory, published 3 May 2026: "JWT authentication can be bypassed when a token is signed using an unsupported algorithm, allowing unauthorized access." NVD's record, published 6 August: "The JWT authentication mechanism accepts tokens signed with algorithms other than those explicitly configured or supported", leading to unauthorized access and potential full account takeover.

Neither mentions path traversal. Neither mentions file upload. The structured field is right, and the sentence a human reads first is describing a different class of vulnerability.

What that does not establish. It does not establish that the entry is wrong to act on: the CVE is correct, the products are correct, the exploitation assessment is correct, and the deadline stands. It does not establish that WSO2's products have no path traversal flaw, only that this identifier is not one. It does not establish how the wording came about, and CISA has not been asked. And it does not establish that anyone has been harmed by it.

What it establishes is that a defender who triages on the name is looking for the wrong thing in the wrong place, and that nothing in their tooling will tell them.

Why the wrong name is worse than no name

Consider what each reading produces in practice, because the two vulnerability classes lead to opposite work.

If you believe this is a path traversal leading to file upload, you go looking at upload endpoints, at write permissions on directories, at web server configuration, at file type validation. You ask whether your deployment exposes an upload path at all, and if it does not, you may reasonably conclude your exposure is limited.

What the flaw actually is: the JWT authentication mechanism accepts a token signed with an algorithm it was never configured to accept, and validates it anyway. So an attacker mints a token, the gateway believes it, and they are authenticated. WSO2's own wording is that successful exploitation may lead to compromise of administrative accounts and full account takeover.

The defensive questions are entirely different. Which algorithms does the deployment accept, and is that list enforced rather than advertised. What has been authenticated recently that should not have been. Are there sessions or tokens to invalidate. Is there anything in the logs that looks like a valid session with no corresponding login.

And this is the part that turns a labelling error into an operational one: the record carries forensicTriage: Yes, which asks agencies to go and look for evidence of compromise. Looking for evidence of a file upload that never happened produces a clean result and a closed ticket.

The same identifier as described by the catalogue's free text, by the catalogue's own structured field, and by the two sources the catalogue cites. All read on 26 September 2026.

Where it is written	What it says the flaw is	Class
KEV vulnerabilityName	Path traversal	CWE-22, if it were true
KEV shortDescription	Path traversal to unrestricted file upload to remote code execution	CWE-434, if it were true
KEV cwes field	Improper verification of cryptographic signature	CWE-347
WSO2 advisory, 3 May	JWT bypassed when a token is signed with an unsupported algorithm	CWE-347
NVD record, 6 August	JWT mechanism accepts tokens signed with unconfigured algorithms	CWE-347

The dates, which are their own story

WSO2 published its advisory on 3 May 2026. The CVE reached NVD on 6 August. The catalogue entry appeared on 24 September, with a due date of 27 September.

That is 144 days from the vendor advisory to the catalogue, and 49 days from the NVD record. Then three days to remediate.

The scoring is worth a line too, because it is unusually careful and almost nobody will see it. WSO2 assigned 10.0, with a scope change, and then published a second figure in the same breath: 9.8 for single tenant deployments, on the reasoning that the impact is contained within one security authority boundary. A vendor publishing its own downward adjustment, with the reason attached, is better practice than the round number it started from, and it is carried in the NVD description rather than in a score field, so most tooling will only ever show the 10.0.

CISA's own SSVC assessment on the same NVD record reads exploitation: active, automatable: yes, technicalImpact: total. That is consistent with the catalogue entry and it is the answer to anyone who suspects the addition itself was hasty. The decision is well evidenced. It is the sentence wrapped around it that is wrong.

The general shape, because this is not one bad record

Every catalogue, feed and dashboard in this field mixes two kinds of content. There are controlled values, drawn from fixed lists, copied between systems and validated on the way: the identifier, the CWE, the dates, the product names, the flags. And there is prose, written once by a person to make the record legible, never validated against anything, and read first by everybody.

The prose is the part that reaches a human, and it is the only part with no integrity check. That is the structural problem, and it produces the same failure in several places this site has already looked at: a field that changes with nothing recording that it changed, a version string that cannot represent a second release, a console that reports what an agent once said rather than what the device does.

The common feature is not carelessness. It is that the human-readable layer and the machine-readable layer are maintained by different processes, and only one of them is checked.

What to do about it

The question this leaves

It would be easy and wrong to write this as an attack on the catalogue. The catalogue is the single most useful public artefact in vulnerability management, the entry is correct in every field that a machine reads, and the decision behind it is supported by CISA's own published assessment. One sentence in it is wrong.

But that sentence is the product. Almost nobody reads a CWE. They read a name in a ticket, and the name here sends them looking for a file that was never uploaded, on a record that explicitly asks them to go looking for evidence of compromise.

So the question for your own process: when the prose and the structured fields in a record disagree, which one does your organisation act on, and do you know the answer because you decided it, or because of how your tooling happens to render a row?