CVE-2026-8785: Apache JSPWiki XSS via crafted RSS feed content
TL;DR - Apache JSPWiki 2.12.0 through 2.12.2 contains an XSS flaw tied to crafted RSS feed content. - Upgrade to 2.12.3 if you run any affected release. - No confirmed in-the-wild exploitation or public PoC is known from the cited primary sources.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-8785 |
| CVSS score | 6.5 (Medium) |
| Attack vector | Network |
| Auth required | None |
| Patch status | Fixed in Apache JSPWiki 2.12.3 |
What happened and why it matters
CVE-2026-8785 is a cross-site scripting (XSS) vulnerability in Apache JSPWiki. The NVD record states that it affects Apache JSPWiki from 2.12.0 before 2.12.3, and Apache’s release materials describe the issue more specifically as “possible XSS via crafted RSS feed content.” That wording matters because it narrows the likely attack path: untrusted content originating from an RSS feed appears to be rendered in a browser without adequate neutralization.
For defenders, this is not just “another medium.” Wiki platforms often sit close to internal documentation, admin workflows, and authenticated browser sessions. Even when XSS requires user interaction, that interaction can be as simple as a user or administrator viewing a page, feed widget, or related content block. In practice, that can lead to session theft, malicious actions performed in the victim’s browser context, or content tampering visible to other users. The impact is limited compared with server-side RCE, but it is still meaningful in environments where JSPWiki is exposed to untrusted contributors or internet-facing content.
Exploitation status: what is known and what is not
Based on the supplied primary sources, there is no confirmed in-the-wild exploitation of CVE-2026-8785. It is not listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog, which means there is no KEV-backed evidence of active exploitation at this time. That does not prove nobody is exploiting it; it only means there is no CISA-confirmed record in KEV.
Likewise, from the research note provided, no public proof-of-concept (PoC) is known in the cited sources, and no vendor statement indicates observed attacks. That is the defensible position. Security teams should avoid overstating this issue as “actively exploited” unless they have their own telemetry or later intelligence showing otherwise. In the absence of public exploit data, defenders should assume opportunistic exploitation is still possible because the issue is remotely reachable and the vulnerable input path involves rendered content.
| Exploitation question | Status |
|---|---|
| Confirmed exploited in the wild? | No evidence from cited primary sources |
| CISA KEV listed? | No |
| Public PoC known? | None identified from cited primary sources |
| Vendor reported attacks? | No such claim in provided sources |
Affected versions and fixed release
The affected version range is explicitly stated in primary sources: Apache JSPWiki 2.12.0, 2.12.1, and 2.12.2 are vulnerable. The fixed version is Apache JSPWiki 2.12.3. If you are running anything in the 2.12.0 before 2.12.3 range, treat the instance as affected until verified otherwise.
Apache’s release guidance is straightforward: users on 2.12.0–2.12.2 should upgrade to 2.12.3. There is no source-backed indication in the supplied references that an alternative patched micro-release exists within the affected line. If your asset inventory only records “2.12.x,” verify the exact build. In SMB and legacy environments, wiki applications are often manually deployed and under-documented, so version drift is common.
| Version | Status |
|---|---|
| 2.12.0 | Affected |
| 2.12.1 | Affected |
| 2.12.2 | Affected |
| 2.12.3 | Fixed |
Technical Notes
A simple version check on a Linux host may look like this, depending on how JSPWiki is deployed:
find /opt /srv /var/lib/tomcat* -iname "*jspwiki*" 2>/dev/null
find /opt /srv /var/lib/tomcat* -iname "pom.properties" -path "*jspwiki*" 2>/dev/null -exec grep -H "version=" {} \;
If JSPWiki is deployed as a WAR under Tomcat, check the deployed artifact and application logs:
ls -lah /var/lib/tomcat*/webapps/
grep -RHi "JSPWiki" /var/lib/tomcat*/webapps /var/log/tomcat* 2>/dev/null
If you cannot determine the exact version from files or UI banners, defenders should assume the instance is affected until they can prove it is 2.12.3 or later.
Severity and exploitation conditions
The vulnerability carries a CVSS v3.1 score of 6.5 (Medium) with vector `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N``. The important operational detail is UI:R: user interaction is required. This lowers the immediate urgency relative to unauthenticated server-side flaws, but it does not eliminate risk. XSS in collaboration software is frequently exploited through social engineering, poisoned content, or trusted workflows where users regularly consume feeds and notifications.
The rest of the vector supports realistic exploitation in the right environment. AV:N and PR:N mean the vulnerable condition can be reached remotely and does not require attacker privileges. The confidentiality and integrity impact are both rated low, which fits a browser-side XSS issue rather than a full application compromise. Still, if an administrator or privileged editor views attacker-controlled RSS-derived content, downstream impact can exceed what a base score alone suggests.
Technical context for practitioners
The vendor description, “possible XSS via crafted RSS feed content,” strongly suggests a failure to properly sanitize or encode untrusted feed content before rendering it in the browser. That could mean HTML content from a feed item, title, description, or embedded markup is passed through to a JSP or template without adequate escaping. However, the provided sources do not include a patch diff, code path, or a vulnerable class name, so defenders should not assume a specific stored vs. reflected subtype without more evidence.
Operationally, what matters is the trust boundary. RSS content is often treated as data, but if rendered into HTML views, it becomes active browser content unless filtered. In wiki software, even a narrow XSS path can matter because administrators may browse pages with elevated privileges, maintain plugins, or moderate content. That is why this issue deserves prompt remediation even though it is not currently KEV-listed.
Technical Notes
The known technical facts from source-backed material are:
Type: Cross-site scripting (CWE-79)
Affected: Apache JSPWiki 2.12.0, 2.12.1, 2.12.2
Fixed: Apache JSPWiki 2.12.3
Vendor wording: "possible XSS via crafted RSS feed content"
CVSS: 6.5 (Medium)
Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Unknowns that defenders should note explicitly:
- Exact vulnerable class/template: unknown from provided sources
- Patch commit or code diff: unknown from provided sources
- Public exploit chain: none identified from provided sources
- Reliable CVE-specific IOC set: not published in provided sources
What security teams should do next
First, identify every JSPWiki deployment and verify whether it falls within 2.12.0 through 2.12.2. Because this is a niche application in many environments, it may not be consistently tracked in endpoint or server inventory. Check Tomcat deployments, legacy collaboration servers, and manually maintained WAR files. If you find an affected version, schedule upgrade to 2.12.3 as the default action.
Second, assess whether the instance is internet-exposed or consumes external content feeds. If yes, prioritize faster remediation and increase monitoring on the web tier. Since there is no confirmed public exploitation or PoC in the provided sources, you do not need to trigger incident severity solely on that basis. But if you also observe suspicious script markers in logs, unexplained admin browser behavior, or anomalous content rendering around RSS-fed pages, escalate and investigate for possible browser-side compromise.
For more information on incident response, check out our Incident Response Checklist for Small IT Teams and our FAQ on How Do Attackers Buy Stolen Credentials.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection and exposure assessment
Detection is the hardest part here because the available public detail is limited. Apache’s wording points to crafted RSS feed content, but the provided sources do not identify the exact parser path, templates, or classes involved. That means defenders should focus on behavioral indicators around feed retrieval, rendering, and suspicious markup in content displayed by JSPWiki, rather than relying on a precise exploit signature.
Start by identifying where JSPWiki instances ingest or display RSS content. Look for pages, plugins, widgets, or integrations that fetch and render external feeds. Then review access logs and application logs for requests associated with feed display, unusual parameters, unexpected HTML tags, or JavaScript-looking payloads. If you front JSPWiki with a reverse proxy or WAF, use that layer to hunt for common XSS markers that may appear in requests or downstream responses.
Technical Notes
A practical first-pass grep for suspicious request artifacts in Apache HTTP Server, Nginx, or Tomcat access logs:
grep -RIE '(<script|javascript:|onerror=|onload=|svg|iframe|srcdoc|alert\(|document\.cookie)'
/var/log/apache2/* /var/log/httpd/* /var/log/nginx/* /var/log/tomcat*/* 2>/dev/null
Example log pattern worth investigating:
GET /Wiki.jsp?page=SomePage HTTP/1.1
Referer: https://wiki.example.local/
User-Agent: Mozilla/5.0 ...
...
<rss-content-containing><script>alert(1)</script></rss-content-containing>
If you centralize logs in Splunk, a basic hunt query could be:
index=web (sourcetype=apache:access OR sourcetype=nginx:access OR sourcetype=tomcat:access)
("script" OR "javascript:" OR "onerror=" OR "onload=" OR "iframe" OR "svg" OR "srcdoc")
| stats count by host, uri_path, http_method, clientip, user_agent
| sort -count
For Suricata environments, a generic signature for obvious XSS strings in HTTP traffic can help triage, though it will not be specific to this CVE:
alert http any any -> $HOME_NET any (msg:"Possible XSS payload in HTTP content"; flow:to_server,established; http.request_body; content:"<script"; nocase; classtype:web-application-attack; sid:1008785; rev:1;)
Because there is no publicly documented exploit pattern tied specifically to JSPWiki’s RSS handling in the provided sources, defenders should treat all detections here as hunting aids, not deterministic indicators of CVE-2026-8785 exploitation.
Mitigation and patching guidance
The primary remediation is clear: upgrade Apache JSPWiki to version 2.12.3 or later. Apache explicitly states that 2.12.3 fixes the issue, and the affected range is 2.12.0 through 2.12.2. If your wiki is internet-facing or exposed to untrusted contributors, this should move up your patch queue even though the CVSS score is medium.
If you cannot patch immediately, reduce exposure around RSS handling. Since Apache describes the issue as possible XSS via crafted RSS feed content, a reasonable temporary workaround is to disable or restrict RSS feed ingestion/rendering features if your deployment uses them. Because the provided sources do not include vendor-documented workaround syntax or exact config keys, be explicit in change records that any workaround is environment-specific and should be tested before production rollout. Also add defense-in-depth controls such as CSP, stricter reverse-proxy filtering, and WAF rules for obvious script content.
Technical Notes
If JSPWiki is deployed as a WAR on Tomcat, a common upgrade workflow looks like this. Adjust paths for your environment:
sudo systemctl stop tomcat
# Back up current deployment
sudo cp /var/lib/tomcat/webapps/JSPWiki.war /var/lib/tomcat/webapps/JSPWiki.war.bak.$(date +%F)
# Deploy the fixed 2.12.3 WAR obtained from your approved internal source/repository
sudo cp JSPWiki-2.12.3.war /var/lib/tomcat/webapps/JSPWiki.war
# Remove exploded app directory so Tomcat redeploys cleanly
sudo rm -rf /var/lib/tomcat/webapps/JSPWiki
sudo systemctl start tomcat
Post-upgrade verification:
grep -RHi "2.12.3" /var/lib/tomcat/webapps /var/log/tomcat* 2>/dev/null
curl -I http://127.0.0.1:8080/JSPWiki/
If immediate upgrade is not possible, temporary containment options include disabling external feed retrieval at the network layer. For example, block outbound HTTP/HTTPS from the JSPWiki host except approved destinations:
# Example only; adapt to your firewall tooling and change process
sudo iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -j REJECT
That workaround is blunt and may affect updates or integrations. Use it only if you have confirmed RSS or external content fetching is part of the deployment and you need an emergency control while planning the 2.12.3 upgrade.