HIGH 7.6

CVE-2026-13707: MediaWiki OAuth Session Fixation Vulnerability (CVSS 7.6)

A session fixation vulnerability has been identified in Wikimedia Foundation's OAuth implementation that allows an attacker to hijack user sessions under specific conditions. Session fixation occurs when an attacker forces a user to use a known session identifier, then exploits that identifier to gain unauthorized access to the user's account. This vulnerability requires the attacker to have some level of access and the user to interact with a malicious link, but once successful, grants the attacker full access to the compromised account's permissions and data.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.6 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L
Weaknesses (CWE)
CWE-384
Affected products
2 configuration(s)
Published / Modified
2026-07-01 / 2026-07-13

NVD description (verbatim)

Session fixation vulnerability in Wikimedia Foundation OAuth. This vulnerability is associated with program files src/Backend/MWOAuthServer.Php. This issue affects OAuth: from * through 1.46.0, 1.45.4, 1.44.6, 1.43.9.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-13707 is a session fixation vulnerability (CWE-384) residing in the MWOAuthServer.php file within Wikimedia's OAuth backend. The vulnerability allows an authenticated or semi-privileged attacker to manipulate session handling during the OAuth flow, causing a legitimate user's session to be associated with a session identifier controlled by the attacker. When the user authenticates, they become bound to this attacker-controlled session, enabling account takeover. The CVSS 3.1 score of 7.6 (HIGH) reflects the requirement for low authentication privileges and user interaction, balanced against high impact to confidentiality and integrity with some impact to availability.

Business impact

Organizations running MediaWiki instances with OAuth authentication face account compromise risk where OAuth-authenticated sessions can be hijacked. This is particularly concerning for wiki deployments serving as content management or collaboration platforms, where account takeover could lead to unauthorized content modification, sensitive information disclosure, and potential lateral movement within integrated systems. The requirement for user interaction somewhat limits attack scale, but successful exploitation still grants attackers the full privileges of compromised accounts.

Affected systems

MediaWiki OAuth is affected across multiple versions: all versions through 1.46.0, 1.45.4, 1.44.6, and 1.43.9. Organizations should verify their exact MediaWiki and OAuth component versions. While version information extends to 1.46.0, the patch status for 1.47 and later versions should be confirmed against official Wikimedia security advisories to ensure no gaps exist in your patching strategy.

Exploitability

Exploitation requires network access and authenticated credentials (PR:L), making it less immediately exploitable in open-access scenarios but dangerous in environments where OAuth is used for authenticated collaboration. Successful exploitation also requires user interaction (UI:R), typically clicking a link crafted by the attacker. No exploit code is known to be publicly weaponized as of the advisory date, and this vulnerability is not tracked on CISA's Known Exploited Vulnerabilities catalog, though this does not guarantee absence of active exploitation.

Remediation

Apply patches for affected versions immediately: update to patched releases of 1.46, 1.45, 1.44, or 1.43 as appropriate for your deployment. Wikimedia has released security updates addressing this issue; consult the official Wikimedia security advisories for exact patch version availability. If immediate patching is not feasible, consider temporarily disabling OAuth-based authentication in favor of alternative authentication mechanisms, or restricting OAuth access to trusted internal networks only.

Patch guidance

Obtain patches from Wikimedia Foundation's official security advisories and release notes. Download and test patches in a staging environment before production deployment to ensure compatibility with your MediaWiki configuration and extensions. Apply patches following your standard change management procedures. Given the HIGH severity and account compromise nature of this vulnerability, expedited testing and deployment is warranted—aim for completion within 7–14 days depending on your environment's risk profile.

Detection guidance

Monitor OAuth session handling for anomalies: look for session identifiers established by one user being accessed by another, or unusual patterns of session creation preceding user authentication. Enable MediaWiki logging for OAuth events and review logs for: (1) multiple failed OAuth authentications from the same user, (2) session IDs appearing in logs before corresponding successful authentication, and (3) subsequent account activity inconsistent with user behavior baselines. Implement network detection rules to flag suspicious OAuth callback URLs or parameter tampering.

Why prioritize this

This vulnerability warrants HIGH priority due to its impact on account confidentiality and integrity, the relative ease of exploitation (low privilege, but user interaction required), and the critical nature of OAuth in modern authentication stacks. Although not yet tracked on CISA's KEV list, the session fixation class of vulnerability has a proven attack history. Prioritize patching for MediaWiki instances used in high-value collaboration or content management contexts, and for instances that serve external users or contain sensitive information.

Risk score, explained

The CVSS 3.1 score of 7.6 reflects: Network-based attack vector (AV:N) with low attack complexity (AC:L), but requiring low privileges (PR:L) and user interaction (UI:R). The impact is High for confidentiality and integrity (account takeover), with Low impact to availability. This places it firmly in the HIGH severity tier—serious enough to demand rapid response, but not at the critical severity level that would indicate widespread, unauthenticated, or immediate widespread exploitation.

Frequently asked questions

Do we need to patch if we don't use OAuth for authentication?

If your MediaWiki deployment does not use OAuth or relies exclusively on native MediaWiki user authentication, this vulnerability does not directly affect you. However, verify that OAuth extensions are not enabled or used by third-party integrations, as some environments enable OAuth for single sign-on even if not obviously configured.

What is session fixation and why is it dangerous?

Session fixation occurs when an attacker pre-sets a session ID and tricks a user into authenticating with that ID. The attacker then reuses that same ID to access the account. Unlike session hijacking (stealing an existing session), the attacker knows the session ID from the start, making it easy to impersonate the user after they log in. In an OAuth context, this can compromise accounts across multiple integrated services.

Does patching require downtime?

Patching depends on your deployment and your MediaWiki configuration. Many updates can be applied with minimal downtime by using MediaWiki's built-in update scripts, though it is advisable to schedule patching during a maintenance window to avoid disruption to active users and to allow for rollback if issues arise.

Are there indicators of compromise we should hunt for?

Yes. Review OAuth-related logs for: sessions initiated without corresponding user login events, session IDs appearing in logs before authentication, geographic or device inconsistencies for a single session, and unusual account activity following OAuth events. If you suspect compromise, reset affected user passwords, audit OAuth-linked accounts, and review account activity logs for unauthorized changes.

This analysis is provided for informational and educational purposes. Patch version numbers, affected versions, and KEV status are based on published advisory data as of the analysis date; always cross-reference with official Wikimedia Foundation security advisories and your internal vulnerability management processes. No exploit code or weaponized proof-of-concept is provided or endorsed. Security teams must independently verify patch applicability, test in non-production environments, and follow their organization's change management and risk governance procedures. This document does not constitute legal, compliance, or tactical incident response advice. Source: NVD (public-domain), retrieved 2026-08-10. Analysis generated by SEC.co (claude-haiku-4-5).