CVE-2025-4036 is a medium severity flaw (CVSS 6.3) in Novel 3.5.0, a Java project from xxyopen. It affects the updateBookChapter function of AuthorController.java, in the chapter handler component, where a user can change chapters through a function that does not check ownership properly. No fix is named, so restrict access and watch the repository.
What's affected
The record names Novel 3.5.0. For Novel-Plus the range is given as "up to" a specific commit, which means every build up to and including that commit, not a numbered release. The affected file is src/main/java/io/github/xxyopen/novel/controller/author/AuthorController.java.
The record says the vendor was contacted early about the disclosure but did not respond in any way. It also says the exploit has been disclosed to the public and may be used. No fixed version or commit is named in the record, and I could not confirm one from the references, so check the project repository before assuming a fix exists.
The CVSS vector shows network access, low complexity and a low privilege account. A logged in user, which on a public fiction site may be any registered reader or author, can reach it.
How to check if you're exposed
- Find out whether you run this project, or a fork of it. Search your repositories and servers for the package name com.java2nb or io.github.xxyopen.
- Find the commit or release you built from.
- Open AuthorController.java and read how the function checks who is calling it.
- Check the access logs of the admin or author application for requests to the matching endpoint.
git log --oneline -1
grep -rn "updateBookChapter" --include=*.java .
Run these in your own checkout. The first line shows the commit you are on, and the second shows where the function lives.
What to do now
- Put the admin or author area behind a VPN, an allow list or a gateway that requires login, so the endpoint cannot be reached from the open internet.
- Add a server side check that the signed in author owns the book before the chapter is changed, and reject the request otherwise.
- Watch the project repository for a fix, and read the change before you merge it. If you maintain a fork, patch it yourself.
- Review logs for past calls to the endpoint and check whether data has changed that should not have.
- Keep a record of the decision, so the exposure is tracked until the fix lands.
Why it matters
The record maps this issue to CWE-266 (incorrect privilege assignment) and CWE-284 (improper access control). The check that should decide who may call the function is missing or too weak. The code runs for a caller who should have been refused, which is the core of broken access control.
This kind of flaw is easy to miss in testing because the feature works as designed for the right user. It only shows when someone tries the request as the wrong user. The score of 6.3 reflects the limited impact the record describes, not a licence to ignore it.
This CVE is not on the CISA Known Exploited Vulnerabilities list. The silent vendor is the bigger risk, because you may wait a long time for an upstream fix. Our free in-browser dependency scan can check the libraries in a Java project like this one, which is worth doing while you are looking at it.
Quick check
Which version should I upgrade to?
The record does not name a fixed version or commit, and the vendor did not respond to the reporter. Check the project repository, and restrict access until a fix is confirmed.
Sources
The CVE record also lists third party write-ups and a VulDB entry. They are not vendor advisories, and this post does not reproduce any exploit detail from them.
Last reviewed: 18 October 2026.
