CVE-2026-86718 is a high severity cross-site request forgery in WWBN AVideo through commit c3edcc27. The deleteHistory.json.php and finishAll.json.php endpoints change global live state on a GET request with no token check, so an administrator who visits a hostile page can lose history. No patched version was listed.
What's affected
Affected: WWBN AVideo up to and including commit c3edcc274c389816d434acadac07ee78eaf330c1 (master, 2026-08-23). The files are plugin/Live/view/deleteHistory.json.php and plugin/Live/view/finishAll.json.php. The GitHub advisory lists patched versions as "None" at the time I read it.
On severity the sources agree: the record shows CVSS 3.1 at 7.1 (High), and VulnCheck also shows 7.1 on CVSS 4.0, with user interaction required. The impact is integrity of live stream history, with a smaller availability effect. Nothing I read reports exploitation in the wild, and the CVE is not in CISA KEV.
How to check if you're exposed
AVideo is usually installed from the project's Git repository, so the commit you run is the version. From the install directory:
git log -1 --format="%H %cd" --date=short
Compare the date and hash with the affected commit, c3edcc274c389816d434acadac07ee78eaf330c1 (master, 2026-08-23 per the GitHub advisory). Anything at or before that commit is in range. If you run a tagged release, note that the advisory names a master commit, so read the project's security advisories page for the first release or commit that fixes the issue.
Then check whether the plugin named in the advisory is present and enabled in your install (the plugin directory lists them), since an unused plugin is not exposed in the same way, although the files may still be on disk and reachable by URL.
What to do now
- Check your AVideo commit or release against the affected range above.
- Read the AVideo security advisories page for the first fixed commit or release, and update to it as soon as one is listed. At the time of writing the GitHub advisory showed patched versions as "None".
- If you can, block GET requests to the two named files at your reverse proxy, or require a custom header that browsers will not add to cross site requests.
- Review web server and application logs for unusual requests to the endpoint named in this post.
- Treat the instance as sensitive: keep admin sessions short and avoid browsing other sites while logged in as an administrator.
Why it matters
The weakness is cross-site request forgery (CWE-352). The two endpoints check only that the caller is an administrator, then act on a GET request. The application's CSRF guard, per the advisory, runs only on POST requests to JSON endpoints, so a GET never reaches it. A hostile web page can therefore make an administrator's browser fetch the URL, and the browser sends the admin session along.
The consequence is loss of data, not theft: all live transmission history deleted, or live sessions marked finished. For a streaming operator that history may be the record used for billing, moderation or compliance, so losing it matters.
The advisory's suggested fix is to require POST and validate a token at the top of each file. That is the right shape of fix for any state changing endpoint: never mutate on GET, and always check a token.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does the attacker need a login?
No account is needed, but an administrator must visit a page the attacker controls while signed in.
Is there a patch?
The GitHub advisory listed none when I read it. Check the project for a newer commit.
Sources
Last reviewed: 18 October 2026.
