Attackers began probing WSO2's JWT bypass 133 days after the fixes went out

The advisory states the condition and not the code path. Authentication is bypassed when the JWT is signed using an unsupported algorithm ^[1]. A verifier that handles that case correctly treats an unrecognised alg as a terminal failure and ends the request. On the affected versions the request continues into an authenticated context ^[1]. The published vector supplies the rest of the precondition: AV:N, AC:L, PR:N, UI:N ^[2]. Nothing has to be phished and nobody has to click, which is why the dev.to writeup expects business users to notice no anomaly at all ^[15]. The attacker needs a route to the vulnerable JWT authentication process, from the internet or from any reachable network ^[14].

Two vectors are published for the same CVE, and one metric moves between them. The 10 uses S:C. The 9.8 for single-tenant deployments uses S:U, with AV:N/AC:L/PR:N/UI:N and C:H/I:H/A:H identical in both strings ^[20]. WSO2 says the adjustment reflects that the impact is contained within a single security authority boundary ^[6]. The gap between the two scores is 0.2 points ^[24].

The advisory is at version 1.0.0 and credits the Hacktron Team with reporting the issue ^[3][8]. The first exploitation attempts watchTowr observed came 133 days after it was published ^[19].

A forged token aimed at a product that does not have the flaw is what untargeted scanning looks like. A miss in your own logs does not establish that a correctly aimed request would also miss ^[10].

The solution section gives subscription holders an update level to reach, and community users the public fixes, with migration to an unaffected version as the fallback ^[7]. Credential rotation is absent from it. Updating repairs the verifier, but the consumer keys and secrets of registered applications that the replay recovered keep working after the update ^[12].

Working out whether anyone got in needs the token header. The dev.to analysis notes that JWT header contents are not visible in standard URL logs, so the signing algorithm, the issuer and the signature verification result have to be cross-referenced against existing authentication and API audit logs ^[16]. It also points at API Manager audit records for access and changes to registered applications, consumer keys and secrets, administrators, and backend definitions ^[22]. Those records only answer the question if retention reaches back past mid-September ^[9].