CVE-2025-12925: 
NixOS vulnerability analysis and mitigation

CVE-2025-12925 is a Missing Authorization vulnerability in rymcu/forest, a modern knowledge community backend built with SpringBoot, Shiro, MyBatis, JWT, and Redis. The flaw affects the UserDicController.java file (functions getAll, addDic, getAllDic/editDic, and deleteDic) in all versions up to and including commit de53ce79db9faa2efc4e79ce1077a302c42a1224 (≤ v1.0). Because forest operates on a rolling release model, there are no discrete version numbers for affected or patched releases. It carries a CVSS v3.1 base score of 9.8 (Critical) (Feedly, GitHub Issue). The vulnerability was reported on October 23, 2025, and published on November 10, 2025.

The root cause is CWE-862 (Missing Authorization) and CWE-284 (Improper Access Control): none of the four REST endpoints in UserDicController.java carry any authentication or authorization annotations (e.g., @RequiresPermissions, @RequiresRoles, or token validation), unlike other controllers in the same codebase such as ArticleController (GitHub Issue). The vulnerable endpoints are:

• GET /api/v1/lucene/dic/getAll — unauthenticated dictionary enumeration
• POST /api/v1/lucene/dic/addDic/{dic} — unauthenticated dictionary entry creation
• PUT /api/v1/lucene/dic/editDic — unauthenticated dictionary entry modification
• DELETE /api/v1/lucene/dic/deleteDic/{id} — unauthenticated dictionary entry deletion

Each write operation also triggers writeUserDic(), which rewrites the lucene/userDic/userDic.dic file on disk and calls Dictionary.getSingleton().updateUserDict() to reload the Lucene tokenizer in real time. No input validation or rate limiting is applied. The vulnerability was discovered via static analysis using the IRify tool (GitHub Issue).

An unauthenticated remote attacker can read, create, modify, and delete entries in the system-wide Lucene user dictionary, which directly affects full-text search across all platform features including article search, user search, portfolio search, and tag recognition (GitHub Issue). Integrity impacts include search result manipulation (injecting competitor terms, spam, or offensive content), while availability impacts include denial of service through dictionary flooding (exhausting disk space), rapid file rewrites (I/O spikes), or deletion of all entries to break search functionality. Confidentiality is also affected, as the getAll endpoint exposes proprietary business terminology and custom search terms without authentication (Feedly).

A proof-of-concept is publicly available in the GitHub issue report, demonstrating unauthenticated HTTP requests to all four vulnerable endpoints (GitHub Issue). No authentication, special privileges, or user interaction are required, making exploitation trivial from any network location. There is no evidence of active in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.038% (0.000380), indicating a currently low probability of widespread exploitation (Feedly).

1. Reconnaissance: Identify internet-facing rymcu/forest instances (e.g., via Shodan or Censys searching for the application's fingerprint or known API paths such as /api/v1/lucene/dic/getAll).
2. Enumerate dictionary entries: Send an unauthenticated GET request to enumerate existing dictionary data and understand the platform's terminology:

   GET /api/v1/lucene/dic/getAll?page=0&rows=100 HTTP/1.1
   Host: <target>
   Accept: application/json

3. Inject malicious dictionary entry: Send an unauthenticated POST request to add a malicious or spam term to the system-wide Lucene dictionary:

   POST /api/v1/lucene/dic/addDic/malicious_term HTTP/1.1
   Host: <target>

   This triggers a file system write to lucene/userDic/userDic.dic and a live Lucene dictionary reload.
4. Modify existing entries: Send a PUT request to overwrite an existing dictionary entry, redirecting search results:

   PUT /api/v1/lucene/dic/editDic HTTP/1.1
   Host: <target>
   Content-Type: application/json
   
   {"id":1,"dic":"manipulated_term"}

5. Delete entries for DoS: Send DELETE requests to remove critical dictionary entries, breaking domain-specific search functionality:

   DELETE /api/v1/lucene/dic/deleteDic/<id> HTTP/1.1
   Host: <target>

6. Amplify DoS: Automate rapid POST requests to flood the dictionary with millions of entries, exhausting disk space and triggering continuous I/O-intensive file rewrites and Lucene reloads (GitHub Issue).

• Network: Unauthenticated HTTP GET requests to /api/v1/lucene/dic/getAll; unauthenticated POST requests to /api/v1/lucene/dic/addDic/<term>; unauthenticated PUT requests to /api/v1/lucene/dic/editDic; unauthenticated DELETE requests to /api/v1/lucene/dic/deleteDic/<id>; high-volume repeated requests to any of these endpoints from a single IP.
• File System: Unexpected or frequent modifications to lucene/userDic/userDic.dic; unusual growth in the lucene/userDic/ directory; new or modified dictionary files with unfamiliar or spam content.
• Logs: Application access logs showing requests to /api/v1/lucene/dic/* endpoints without authentication tokens or session cookies; Java stack traces related to UserDicServiceImpl.writeUserDic() or Dictionary.getSingleton().updateUserDict() during unexpected times.
• Process/Application Behavior: Sudden degradation or failure of search functionality across the platform; unexpected spikes in disk I/O or CPU usage correlated with dictionary reload operations (GitHub Issue).

Update rymcu/forest to the latest commit after de53ce79db9faa2efc4e79ce1077a302c42a1224, which addresses this issue as tracked in the GitHub repository (GitHub Issue). As an immediate workaround, add @RequiresRoles(value = "admin") annotations to all four endpoints in UserDicController.java and implement input validation (length limits, character allowlists) on the addDic and editDic endpoints. Additionally, apply network-level access controls (e.g., firewall rules or API gateway policies) to restrict access to the /api/v1/lucene/dic/* endpoints to trusted administrative IP ranges only, and implement rate limiting to mitigate DoS risk.

RedPacket Security flagged the vulnerability via social media shortly after publication (RedPacket Security). Red Hat's security advisory page also indexed the CVE (Red Hat). No significant broader media coverage or notable researcher commentary beyond the initial disclosure has been identified.