The fix shipped on March 10, 2026 and was announced five days later as the third bullet in a post about a Chrome extension release; the CVE describing it as unauthenticated account takeover appeared on September 2.
What happened
At 1:17 a.m. UTC on Wednesday, September 2, 2026, CVE-2026-84699 appeared in the National Vulnerability Database. Its description reads: “Team Password Manager before 14.184.308 fails to enforce authentication requirements in the local account password reset flow. Unauthenticated attackers can reset local account passwords and authenticate as those users to gain unauthorized access.”
The record is scored CVSS v3.1 9.1 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, and CVSS v4.0 9.3, both by [email protected]. VulnCheck assigned the identifier as a third-party CNA and published its own advisory dated September 1, 2026, crediting the finding to Aidan Stansfield. The weakness is CWE-640, a weak password recovery mechanism for a forgotten password. Affected versions are everything below 14.184.308. The fixed version is 14.184.308.
That fixed version is not new. Team Password Manager’s own changelog dates 14.184.308 to 20260310 — March 10, 2026 — and lists four items under it. The first reads, in full: “Corrected vulnerabilities in user password reset.” The other three are an upgrade of phpseclib to 2.0.51, a patch to Bootstrap’s JavaScript for several XSS issues, and a PHP 8.4 bug in the SAML library.
The vendor’s public announcement of that release came on March 15, 2026, in a blog post whose subject is the pairing of Chrome extension 6.42.27 with TPM 14.184.308. Its lead item is the browser extension: “Additional data for the browser extension. The application now provides the extension with additional information required for the new features.” Further down, under a heading of “Security improvements,” it says: “Several security-related updates have been implemented, including: Fixes for vulnerabilities in the user password reset functionality. Patches applied to Bootstrap JavaScript components to address multiple XSS vulnerabilities.”
Between the fix and the record describing it, 176 days elapsed. For all of them, the only public account of a 9.1-scored unauthenticated authentication bypass in a password manager was the phrase “vulnerabilities in the user password reset functionality,” sitting beneath a note about browser extension telemetry.
Why it matters
CWE-640 is a bad class of flaw in any product. In a password manager it is the worst available one, because the entire security value of the product is that a single authentication decision gates everything behind it. An attacker who can reset a local account’s password and log in as that account does not need to break any of the cryptography the product advertises; they walk through the door the product exists to guard. The CVSS vector reflects exactly that shape — confidentiality high, integrity high, availability none. Nothing goes down. Everything is read.
Team Password Manager is installed on the customer’s own server. Its changelog is full of the concerns that go with that: PHP 8.4 compatibility, a phpseclib upgrade, a SAML library bug, a session cookie name default. There is no vendor-side deployment that silently brings every tenant current. Somebody at the customer has to decide to apply the update, and the document they use to make that decision is the changelog and the release post.
Which is where the wording does its damage. “Corrected vulnerabilities in user password reset” is not false. It is not evasive in any legal sense. It is simply uninformative in the one dimension that determines behavior: whether the flaw requires an attacker to already have an account. An administrator reading “corrected vulnerabilities in user password reset” reasonably files it next to the Bootstrap XSS patches and the phpseclib bump in the same release — housekeeping, worth doing at the next maintenance window. An administrator reading “an unauthenticated attacker on the network can reset any local account’s password and log in as that user” schedules the change tonight, and audits afterward. Those are different Tuesdays, and the sentence the vendor published cannot distinguish between them.
This is now the sixth time in a week that Severity Daily has found a critical fix described in a vendor’s own release notes as routine maintenance. WPLP Cookie Consent called an unauthenticated file upload reaching code execution “security enhancements and improved validation across the codebase.” Nokri called an unauthenticated administrator takeover “hardened database queries and token generation.” The pattern holds across a WordPress plugin, a marketplace theme, an IDE, and now an enterprise credential store, which suggests it is not a property of any one market segment. It is what happens when release notes are written for prospective buyers rather than for the operators who already run the thing.
The 176-day record gap has a structural cause worth naming, because it is not the vendor sitting on something. Team Password Manager is not a CNA. Nobody inside the company had a mechanism for producing a machine-readable vulnerability record even if they had wanted one. The identifier exists today because an outside researcher reported the issue and a third-party CNA — VulnCheck, which has been generating a large share of the records this publication has covered in the past week — eventually assigned it. Vendors outside the CNA system do not produce late records. They produce no records, and the timing is then set entirely by whoever picks the work up.
Two details temper the urgency, and both should be read carefully rather than as reassurance. The first is scope: the record says “local account.” Team Password Manager supports LDAP, Active Directory, and SAML authentication in addition to local accounts, and organizations that authenticate everyone through an identity provider are less exposed by the plain reading of the description. Less, not un- — nearly every such deployment keeps at least one local break-glass administrator, and that account is the highest-value target in the system.
The second is that no exploitation has been reported. There is no proof of concept in the public sources reviewed, no KEV listing, and no federal deadline; the NVD record carries no cisaExploitAdd or cisaActionDue field. The catch is that the record is still in “Received” status at NVD, meaning it has not been analyzed and carries no CPE configuration data. Vulnerability scanners that match on CPE will not flag affected installations until that analysis completes. For an unknown number of additional days, the gap between the record existing and the record being actionable stays open.
One more line in the changelog is worth noting. The release after this one, 14.190.309, adds passkey authentication and “Protection against login timing attacks (for local users).” The local authentication path was evidently still receiving attention after March.
What to do
Check your version now. Anything below 14.184.308 is affected, which by the record’s own range means every release the product has ever shipped up to March 10, 2026. The version is visible in the application’s about or admin information page.
Upgrade to a current release, not merely to 14.184.308. The fixed version is nearly six months old, and at least two feature releases have followed it, one of which further hardened local authentication.
Treat the interval as potentially exposed, not as clean. If your installation ran a pre-14.184.308 build with the web interface reachable from anything broader than a management network at any point since 2026 began, review the password reset and authentication logs for that period, look for local accounts whose passwords changed without a corresponding user request, and check for sessions or API tokens you cannot account for.
Reduce the local-account surface. If your organization authenticates through LDAP, Active Directory, or SAML, enumerate the local accounts that still exist, remove the ones nobody uses, and make sure the break-glass account is not reachable from the same place an attacker would be.
Do not put the management interface on the public internet. The vector is network-reachable with no privileges and no user interaction. Everything about this flaw is bounded by who can reach the login page.
Sourcing note
Checked: the NVD record for CVE-2026-84699 (published September 2, 2026 at 1:17 a.m. UTC, CVSS v3.1 9.1 and v4.0 9.3, both scored by VulnCheck, CWE-640, status “Received,” no CISA KEV fields); VulnCheck’s advisory for the same issue, dated September 1, 2026, giving the affected range as everything below 14.184.308 and crediting Aidan Stansfield; Team Password Manager’s own changelog entry for 14.184.308 dated 20260310; and the vendor’s release post for Chrome extension 6.42.27 and TPM 14.184.308, dated March 15, 2026.
Unresolved: the vendor has published no security advisory for this issue under any identifier found in this review, and no vendor statement acknowledging CVE-2026-84699 exists as of publication. The exact technical mechanism — what check is missing in the reset flow — is not described in either the CVE record or the vendor’s notes, and no proof of concept was located. Whether any customer was exploited during the 176 days before the record appeared is unknown and, given the absence of a vendor advisory, likely to stay that way.
Install-base figures for Team Password Manager are not published by the vendor and none are asserted here. CISA’s pages return 403 to automated fetching, so KEV state was checked through the NVD record’s CISA fields rather than cisa.gov directly.
