Seventeen CVE records for the self-hosted video platform AVideo landed in NVD this afternoon, and all seventeen draw the affected-version line at the same 40-character git commit hash — a boundary no operator running a release can check, because the last tagged release is from April 2024.
What happened
At 1:16 p.m. UTC on September 12, 2026, seventeen new CVE records for WWBN AVideo were published: CVE-2026-90536 through CVE-2026-90552. All seventeen were assigned by VulnCheck, which appears as [email protected] in the sourceIdentifier field of each record. A keyword query against the NVD API restricted to records published today returns exactly seventeen results, all AVideo.
CVSS v3.1 base scores across the batch run from 4.3 to 8.2, all scored by VulnCheck itself. The highest is CVE-2026-90537 at 8.2, with a v4.0 score of 8.8 and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N. Its description reads: “WWBN AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 contains a missing authorization vulnerability in plugin/Scheduler/sendEmail.json.php that allows unauthenticated attackers to access scheduler email jobs by providing a site-wide daily token. Attackers can enumerate scheduler jobs, read private live titles and email addresses, and trigger email sending by supplying any valid daily token obtained from Live pages.”
The rest of the batch is the same species of flaw at different addresses. The descriptions name individual JSON endpoints one at a time — among them playlistsFromUser.json.php, menus.json.php, like.json.php, getBookmarks.json.php, videosAndroid.json.php and mediaSession.json.php — and in each case the endpoint does not check whether the caller is allowed to see or touch what it returns. The recurring consequences named in the records are unauthenticated reads of owner user IDs and email addresses, private playlist names, chapter titles on password-protected videos, and hidden administrative menu entries.
Every record shares one machine value. In the configurations block of all seventeen, the affected range is expressed as version 0 through lessThanOrEqual c3edcc274c389816d434acadac07ee78eaf330c1, with versionType given as git. There is no version number anywhere in the range.
That commit exists. It is authored by Daniel Neto, its message is “Enhance validation logic for stream URLs and keys by adding support for automatic destinations,” and it touches a single file, plugin/Live/view/Live_restreams/add.json.php, adding six lines and removing one. It is an ordinary feature commit. It fixes none of the seventeen flaws; it is being used as a date stamp for when the research was done.
The GitHub advisories the CVE records point to are older than the records. CVE-2026-90536, the adsInfo finding, references GHSA-989c-frwf-gprj, which was published on August 28, 2026 — fifteen days before the CVE existed. That advisory rates the issue Moderate at 5.3, credits the reporter santhreal, states that the vulnerable function “does not call User::canWatchVideo(),” gives its affected range as <= c3edcc274c389816d434acadac07ee78eaf330c1, and lists its patched versions as “None.” Under CVE ID it still says “No known CVE.”
The project’s newest tagged release on GitHub is 29.0, dated April 7, 2024. GitHub’s advisory database returns “280 advisories” for a search on AVideo.
Why it matters
An affected-version field has exactly one job: to let someone who runs the software answer whether they are affected. A 40-character commit SHA answers that question for one kind of reader — someone who deployed from a git checkout and can run git merge-base against it. For everyone else it answers nothing. If you unpacked a tarball, ran an installer, inherited the instance from a contractor, or bought hosting, you have no way to place yourself relative to c3edcc27, and no version string to compare. The record is precise and unusable at the same time.
What makes it worse here is that the release channel is not where this software lives. The last tag is from April 2024, nearly two and a half years before these records. Development happens on master; operators who keep current pull, they do not upgrade to a number. So the commit hash may be the most accurate boundary available — and that is the finding, not an excuse. Every scanner that works by comparing an installed version against an affected range returns nothing for these seventeen CVEs, because there is nothing to compare. That is a silent false negative, and silence is what it looks like from the console.
The second half of the problem is the fix. “Patched versions: None” on the GitHub advisory, paired with an affected range that ends at recent master, has a plain reading: all current code is affected and there is nothing to move to. Most vulnerability workflows do not have a lane for that. They have “patch available, schedule it” and “no patch, apply the vendor mitigation.” Here there is neither, and the only remediation an operator controls is putting something in front of the application.
Then there is the volume. Two hundred and eighty advisories against a single open-source project is not a run of bad luck; it describes how the application enforces authorization. These seventeen records show researchers walking an endpoint list and finding that each JSON handler decides for itself whether the caller is entitled to what it returns. The remedy for a missing call repeated across hundreds of handlers is a default-deny layer that makes the call unnecessary, and only the project can build that. Patching seventeen endpoints leaves the next seventeen.
Severity Daily covered this project a week ago, on September 5, when AVideo’s statistics endpoint was found returning every viewer’s password hash, with the project’s own advisory noting the hash is sufficient to log in — also with no fix named. What is new today is not that AVideo has authorization problems. It is that the second batch arrived with the version boundary degraded from a described release to a raw SHA, and with the same empty patched-versions field. The trajectory is the story.
The record also contradicts itself. VulnCheck’s record for CVE-2026-90536 points at GHSA-989c-frwf-gprj as its primary reference, and that advisory, read today, tells the reader there is “No known CVE” for the issue. For the fifteen days between the two, the flaw was fully public on GitHub and absent from every feed keyed to CVE identifiers — which is most of them.
What to do
If you run AVideo, start from the assumption that you are affected. No release is named as safe, and no patched version exists in any of the seventeen records or in the GitHub advisory behind them.
To place your instance against the stated boundary, from the repository root run git log -1 --format=%H to get your current commit, then git merge-base --is-ancestor c3edcc274c389816d434acadac07ee78eaf330c1 HEAD. A zero exit status means the boundary commit is in your history; a non-zero status means you are behind it, squarely inside the affected range. Only a checkout strictly newer than that commit falls outside the range as written, and even then nothing claims the flaws are fixed there. If you did not deploy from git, the record cannot answer the question and you should treat the instance as affected.
Because there is no patch, the work is in front of the application. At the reverse proxy, require an authenticated session for the *.json.php endpoints under plugin/ that your deployment does not need to expose publicly, starting with plugin/API/get.json.php and plugin/Scheduler/sendEmail.json.php. Deny unauthenticated access to plugin paths you do not use at all, and disable plugins your site does not run.
Treat password-protected and group-restricted content on a public instance as not protected. Several of the records describe unauthenticated retrieval of owner email addresses, private playlist contents, private live-stream titles and restricted video metadata. If any of that material is sensitive, move it off a publicly reachable instance rather than relying on the access controls these records say are absent.
And do not expect your scanner to raise this. Confirm by hand whether AVideo is in your estate, because a product whose affected range is a commit hash will not appear in a version-matched report.
Sourcing note
Checked: the NVD API, queried for records mentioning AVideo published on September 12, 2026, which returned a totalResults of 17 and the range CVE-2026-90536 to CVE-2026-90552 with each record’s score, weakness and version boundary; the individual NVD records for CVE-2026-90536 and CVE-2026-90537, read one at a time for their descriptions, vectors and references; GHSA-989c-frwf-gprj on GitHub, read for its severity, patched-versions field, CVE field and the User::canWatchVideo() language quoted above; the repository page for commit c3edcc274c389816d434acadac07ee78eaf330c1, confirming it exists and what it changes; AVideo’s releases page for the latest tag and its date; and the GitHub advisory database for the advisory count.
Could not complete: the remaining fifteen records were read through the batch query rather than fetched one at a time, so the endpoint names above are not attributed to individual CVE numbers here. An earlier batch-level read of that query returned a score and weakness for CVE-2026-90536 that the per-CVE record contradicted, which is why only individually verified records are quoted with scores. The commit page did not surface a commit date, so none is stated. VulnCheck’s own advisory pages were read for one record only.
Unresolved: whether the project has landed fixes on master since the August 28 advisories, and whether it intends to tag a release; why GHSA-989c-frwf-gprj still reports “No known CVE” on the day a CVE was assigned to it; and whether any of the seventeen duplicate identifiers already issued against this project. No exploitation has been reported by any source we checked. cisa.gov returns 403 to automated fetching, so Known Exploited Vulnerabilities status was checked through NVD’s republication of CISA’s fields, which carries none for these records.