Five more CVE records landed against the open-source video platform on Saturday afternoon, bringing the 30-day total to 46, and not one of them names a version to upgrade to.
What happened
Five CVE records for WWBN AVideo, the self-hosted open-source video-sharing platform, were published to the National Vulnerability Database at 1:18 p.m. UTC on Saturday, September 5, 2026. All five arrived within a second of one another. All five carry [email protected] as the source identifier, meaning VulnCheck assigned them as the CNA. Two are rated critical.
The one that matters most is CVE-2026-86190, scored 9.1. NVD’s description reads: “WWBN AVideo contains a broken access control vulnerability in videoViewsInfo endpoints that returns complete user records including password hashes, recovery tokens, and live session identifiers to unauthenticated callers when a hash parameter is provided.”
The project’s own advisory is more specific than the CVE record. GHSA-82q2-88mq-p44q, published by the AVideo maintainers on August 21, 2026, says the statistics endpoints serialize “the entire joined users record for every viewer, including the password hash, the password-recovery token, and the viewer’s live session identifier.” It puts a number on it: “An anonymous request therefore returns 52 fields per viewer, among them password, recoverPass, email, phone, address, birth_date, isAdmin and session_id.”
The second critical, CVE-2026-86189 at 9.8, is a path traversal in notify.ffmpeg.json.php that lets an unauthenticated caller write a file to a path of its choosing. The authentication in front of it is a token called notifyCode. The project’s advisory, GHSA-cprx-fggj-7vpq, describes the check in one sentence: “notifyCode is tested for non-emptiness only. Its contents are never compared against anything.” AVideo mints those tokens as encryptString(time()), and accepts any string that decrypts to something non-empty — so any ciphertext the site has ever issued, including the video_id_hash values it publishes, satisfies the check.
The other three published Saturday are lower-scored and still worth noting. CVE-2026-86186 (6.5) says the API “fails to enforce rate limits when clients send a bot User-Agent header,” defeating login brute-force protection. CVE-2026-86187 (5.9) says external-login account passwords are generated with rand() rather than a cryptographic generator, “producing only 31-bit integers,” and that “Attackers with access to password hashes can recover plaintext passwords in minutes.” CVE-2026-86188 (7.2) is cross-site scripting reachable by an unauthenticated caller when the YPTSocket plugin is enabled.
The scale is hard to see from any single record. An NVD keyword search for AVideo, bounded to records published between August 6 and September 5, 2026, returns a totalResults of 46. Every one of the records visible in that result set carries VulnCheck as the source. The project’s own GitHub advisory list shows the same burst from the other side: pages of advisories dated August 27 through September 2, most of them credited to a single reporter, rajivraj.
None of the 46 names a fixed version. AVideo’s most recent tagged release is 29.0, dated April 7, 2025 — seventeen months ago. NVD’s affected-version data for both criticals reads as versions 0 through 29.0 inclusive, and every GitHub advisory we read states its affected version as “current (e01e41ecc) and earlier” with “Patched versions: None.”
The severity numbers do not agree, either. For the file-write flaw, the project rated it High at CVSS 8.2, the CVE record says Critical at 9.8, and VulnCheck’s own advisory page gives a CVSS v4.0 score of 9.3. For the data-exposure flaw the ranking inverts: the project called it Critical at 9.8, the CVE record says 9.1, and VulnCheck’s page again says 9.3. A reader checking all three sources gets three numbers per flaw, and the two flaws the maintainer scored 1.6 points apart come out identical under v4.0.
Why it matters
Read CVE-2026-86190 on its own and it is a bad information disclosure: an unauthenticated caller gets email addresses, phone numbers, birth dates and password hashes. Hashes are supposed to be the part you can afford to lose for a while, because cracking costs time and money.
Two other AVideo advisories say that assumption does not hold here. GHSA-fq38-jp6c-q4cx, published by the project on September 1, 2026 and rated Critical at 9.8, states flatly: “Submitting the value of users.password as the password logs the account in. No encodedPass flag is needed; the ordinary browser login form is enough.” Its title says the rest — “any disclosure of users.password is a direct login with no cracking.” That advisory has no CVE identifier yet. And for accounts created through external login, CVE-2026-86187 says the underlying password is a 31-bit rand() value recoverable from its hash in minutes anyway.
So the disclosure is not a step on the way to compromise. On the maintainer’s own account of its code, it is the compromise, and the session_id field in the same response skips the password question altogether by handing over a live administrator session. We have not tested that chain, and no one has published a combined exploit for it; what we are reporting is that three advisories written by the same project about the same codebase, taken together, describe it. Each half is the maintainer’s own statement, not an inference by a third party.
The notifyCode defect is a different and more instructive kind of mistake. The code does real cryptography — it decrypts the token — and then treats the fact that decryption succeeded as proof that the caller was authorized. Nothing checks what came out. That is the same shape as two stories this site has run in the past two days: python-jose accepting a public key as an HMAC secret because the 2024 fix inspected the key’s format instead of its role, and Coolify logging a user in on an OAuth email match alone. In each case a security-relevant value is validated for shape and never for meaning.
The version data deserves its own note, because it will mislead scanners. “Affected: 0 through 29.0” reads like a bounded range with a safe side above it. There is no safe side. 29.0 is the newest release AVideo has ever shipped, so the ceiling of the affected range and the current release are the same build — the same structure this site described in Coolify’s record earlier today, where the affected ceiling 4.3.17 is also the shipping version. A vulnerability-management tool that renders “≤ 29.0” as a range will imply an upgrade path that does not exist.
Finally, the batch. Forty-six CVEs against one project in thirty days, from one CNA and largely one researcher, is the second such burst this week: MOOS-IvP took 33 VulnCheck-assigned CVEs at once on September 4. These bursts are good for the record and hard on defenders. They land as dozens of separate scanner findings against one asset, and the triage question stops being “which of these do I patch” and becomes “do I keep running this at all.” AVideo’s maintainers deserve some credit here: publishing your own advisories with “Patched versions: None” is more candid than the common alternative of sitting on them. Candor does not give an operator anything to install.
What to do
AVideo is self-hosted, so nobody will patch it for you and there is nothing to patch. Treat this as an exposure decision, not a patching one.
- Find it. Look for AVideo installs by their
/objects/path prefix and endpoints such asnotify.ffmpeg.json.phpand thevideoViewsInfoAPI. Shared hosting and marketing-department video portals are where these turn up unrecorded. - Take it off the public internet. With no fixed release available, network exposure is the only control you own. Put the instance behind a VPN or an authenticating proxy.
- Block the two named endpoints at the reverse proxy if the instance must stay reachable. That is a mitigation standing in for a patch, and it addresses only the two flaws with CVEs today, not the other 44.
- Assume every stored hash is already disclosed. Force a password reset for all accounts, invalidate all sessions, and rotate recovery tokens and stream keys. Because the hash functions as a password on this platform, a reset — not a “monitor for misuse” posture — is the containment step.
- Do not triage on the CVE score alone. The maintainer and the CNA disagree by up to 1.6 points and in opposite directions on the two criticals; read the GitHub advisory, which is more specific than the CVE record in both cases.
- Watch the repository’s advisory list, not its releases page. The releases page has not moved since April 2025. The advisory list moves several times a week.
Sourcing note
Checked against primary sources: the five NVD records for CVE-2026-86186 through CVE-2026-86190, retrieved from the NVD API on September 5, 2026; the AVideo project’s own GitHub Security Advisories GHSA-82q2-88mq-p44q and GHSA-cprx-fggj-7vpq (both published August 21, 2026) and GHSA-fq38-jp6c-q4cx (September 1, 2026); VulnCheck’s advisory pages for the two criticals; and the AVideo repository’s releases page. The 46-record count is NVD’s own totalResults for a keyword search bounded to August 6 through September 5, 2026, confirmed on two retrievals with different query forms.
Not resolved: we could not confirm from a primary source whether AVideo has fixed any of these in unreleased code, because the repository’s tagged releases stop at 29.0 and the advisories scope affected versions by commit hash rather than version. We did not attempt to verify the hash-as-password chain against a running instance, and we are not aware of any public exploit that combines the three advisories. GHSA-fq38-jp6c-q4cx carried no CVE identifier at the time of writing. VulnCheck’s advisory pages give a CVSS v4.0 score but no disclosure timeline. No source indicates these flaws have been exploited.