Loading vulnerability…
CVE-2026-48611 is a critical authentication bypass affecting phpBB versions prior to 3.3.17. The flaw is in phpBB's login-link flow, implemented in ucp_login_link.php, which is intended to link external OAuth identities to existing accounts or register new ones. In the vulnerable logic, the auth_provider parameter is attacker-controlled and insufficiently restricted. An unauthenticated attacker can invoke the apache authentication provider instead of the expected OAuth provider by supplying mode=login_link together with attacker-chosen login_link_* data. The apache provider trusts PHP Basic authentication variables (PHP_AUTH_USER/PHP_AUTH_PW) and, in this code path, returns successful authentication for an existing active user when the submitted username matches PHP_AUTH_USER, without verifying the password itself. Because the login-link feature can reach this provider even when Apache-based authentication and OAuth are not configured or enabled, a single crafted unauthenticated request can authenticate as an arbitrary known phpBB user, including an administrator, resulting in full account takeover.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (1 hidden).
This repository is a small standalone Python proof-of-concept exploit for a claimed phpBB authentication bypass tracked as CVE-2026-48611. The repository contains only two files: a README with usage notes and affected-version claims, and a single executable script, exploit.py, which is the clear entry point. The exploit logic is straightforward and operational rather than framework-based. It creates a requests session with TLS verification disabled and a hardcoded browser-like User-Agent. It first requests /index.php to obtain baseline guest cookies. It then sends a crafted POST request to /ucp.php with query parameters mode=login_link, auth_provider=apache, and login_link_poc=1, while also supplying an HTTP Basic Authorization header containing base64(username:x) and standard login form fields. After the POST, it inspects returned phpBB cookies, especially the phpbb3_*_u cookie, to determine whether the session now belongs to a real user instead of the anonymous user. If a non-anonymous session is obtained, it attempts to access /adm/index.php to verify admin-panel reachability. The exploit’s main capability is session acquisition for an arbitrary supplied username on a vulnerable phpBB target, followed by validation of administrative access if that username corresponds to an admin account. It does not deploy malware, shells, or post-exploitation tooling; instead, its output is the authenticated cookie set that can be reused manually in a browser. The README explicitly instructs the operator to align the User-Agent with the browser and replace phpBB cookie values in the browser to continue the hijacked session. Overall, this is a focused web exploit POC targeting phpBB authentication/session handling. It is not a detection-only script, and it contains no obvious destructive or fake behavior. Its success depends on a vulnerable phpBB deployment, knowledge of a valid username, and the target issuing usable phpBB session cookies.
This repository is a minimal single-file JavaScript proof of concept targeting phpBB authentication behavior. The only file, poc.js, defines a username ('test') and issues a browser fetch() request to the current site's /ucp.php endpoint with mode=login_link and auth_provider=apache. It sets an Authorization: Basic header using the chosen username and a dummy password, and also submits form fields login=1, login_username, and login_password. Comments indicate usernames may be enumerated from memberlist.php or memberlist.php?mode=team, and that auth_provider=ldap may also work in some cases. Structurally, this is not a full exploit toolkit or framework module; it is a compact browser-side PoC intended to be executed in the context of the target origin, likely as part of an XSS or manual browser-console test. Its purpose is to demonstrate abuse of phpBB external authentication/login-link handling to attempt unauthorized login or account access for a known username under vulnerable configuration.
19 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
An authentication bypass vulnerability affecting phpBB versions prior to 3.3.17.
An improper authentication vulnerability in the OAuth implementation that can allow account hijacking and unauthorized access, including in default installations even when OAuth is not configured or enabled.
A critical authentication bypass vulnerability in phpBB's login-link flow that allows an unauthenticated attacker to select the apache auth provider and log in as any arbitrary user, including administrators, without a valid password.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.