Secure Login 2FA EUVD-2026-37066

Requires (1) valid first-factor credentials (username and password) for any account on the targeted Jira, Confluence, or Bitbucket instance that has the Secure Login plugin at exactly version 3.4.0.x installed and 2FA enforcement enabled, and (2) the ability to send HTTP requests to the application with an attacker-chosen User-Agent header containing the literal substring 'AtlassianMobileApp' or 'JIRA'. Limiting factors: the attacker cannot exploit this with zero knowledge - a working credential is mandatory (PR:L); the bypass is plugin-specific and does not affect Atlassian-native 2FA, native SSO, or any 2FA solution other than syracom Secure Login 3.4.0.x; instances already upgraded to 3.5.0.0 are unaffected; and full administrative compromise additionally requires that the credential set belongs to an admin account, while non-admin credentials yield only that user's access.

The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H (score 8.7) accurately reflects a network-reachable, low-complexity bypass requiring only one set of valid credentials and no user interaction, with full CIA impact on the Atlassian instance. EPSS and CISA KEV data are not provided in the input, and no public exploit was identified at time of analysis, so likelihood signals are limited; however, the exploitation primitive - adding a header - is so trivial that absence of a published PoC offers little protection. Real-world risk is meaningful in any environment where 2FA was deployed specifically because the first factor (password) was assumed compromised or phishable: credential-stuffing, phishing, and password-reuse attacks that the plugin was bought to stop will now succeed. The honest constraint is that the attacker must already hold a working username/password, which lowers the score below an unauthenticated RCE but does not lower the business impact, since defeating 2FA is the whole point of holding stolen credentials.

An attacker phishes or credential-stuffs a valid Jira account belonging to a system administrator. They send a normal POST to the login endpoint with the stolen username and password, but set 'User-Agent: AtlassianMobileApp/1.0'; the plugin recognizes the mobile substring and skips the TOTP prompt, returning a fully authenticated session cookie. The attacker then uses that session against /plugins/servlet/upm to disable the Secure Login plugin entirely and install a malicious plugin for persistence and arbitrary code execution under the Jira service account.