Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Skip to content
cve.newCreate a CVE report
Check your stack
CVE-2026-84172

Apache Wicket: Component markup is served as a package resource when wicket-core has its own class loader

Products / packages Apache Software Foundation Apache Wicket

Published

Share

Severity and exploitation

Not in CISA KEV

KEV coverage does not rule out exploitation.

KEV checked 14/11/2026, 23:55:31 UTC
apache · CVSS:4.0 · 6.3
Assessment vectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Severity

medium6.3

CVSS measures technical severity, not the likelihood of an attack.

Known exploitation

Not listed in the checked CISA KEV catalog

Absence from CISA KEV does not rule out attacks.

Public exploit

Not established by this record

Missing evidence does not mean no public exploit exists.

Remediation

Fix status not established

No structured fix or guidance is available here. Check the latest publisher advisory.

What this means

Apache Wicket versions 8.0.0-8.19.0, 9.0.0-9.24.0, and 10.0.0-10.11.0 are affected by a vulnerability where component markup is served as a package resource when wicket-core has its own class loader, allowing read-only access to developer-authored template content. An attacker must name a component class to exploit this. The impact is confined to rare deployments where wicket-core is loaded by a class loader that cannot see the application's classes.

Summarized by @cf/meta/llama-3.3-70b-instruct-fp8-fast. Verify details against the original sources.

Attack conditions

No attack-condition excerpt has been identified here. Review the full source description and references for authentication, network access, and configuration requirements.

Review supporting sources →

Affected versions

Check the exact model, release, and any platform requirements against your installation.

Apache Software Foundation · apache

Apache Wicket

3 ranges
apache version evidence

Package identity

pkg:maven/org.apache.wicket/wicket-coreExplore org.apache.wicket:wicket-core →

Identity supplied by apache. Version matching requires compatible range evidence.

Compare with this publisher’s ranges. This does not inspect your installation.

affected

8.0.0 → through 8.19.0

semver versions

9.0.0 → through 9.24.0

semver versions

10.0.0 → through 10.11.0

semver versions

unaffected

unknown

Other versions: unaffected

Automatic dependency matching is unavailable for this record. Use the product evidence and publisher’s instructions to check your installation.

What to do

Compare your installed product and version with the affected versions above. A matching product name alone does not confirm exposure.

No structured fix or remediation guidance is available here. Check the full source description and vendor’s latest advisory for a patch or workaround; do not assume another version is safe.

cve.new guidance unless attributed to a publisher. This page does not inspect your installation.

Public exploit evidence

No public exploit reference is identified in the imported evidence. This is not a claim that no exploit exists.

Original source description

Read the full publisher description

Files accessible to external parties in Apache Wicket.

org.apache.wicket.markup.html.PackageResourceGuard decides whether a file on the classpath may be streamed to a client as a package resource. HTML is on the default allow list, so the only thing that separates a static HTML file, which may be served, from a component's markup template, which may not, is a check for a class file of the same name beside it. That check calls getResource() on the class loader that loaded wicket-core. The resource itself is reached through different class loaders: the scope class is resolved through the application's IClassResolver, which uses the thread context class loader, and org.apache.wicket.core.util.resource.ClassPathResourceFinder#find() then tries the scope class' own loader, the context class loader, and the wicket-core loader last.

Where wicket-core is loaded by a class loader that cannot see the application's classes, the check finds no class file, concludes the file is not a component markup template, and serves it. A request for the package resource URL of a component class then returns that component's markup template with status 200. What is disclosed is developer-authored template content: component structure, developer comments, markup that is rendered only under some conditions, inline script, and the endpoints a template names. Access is read-only, and no user data, credential or session material is reachable this way.

Such a deployment is rare. The ordinary packaging, a web archive with wicket-core in WEB-INF/lib, puts the framework and the application in one class loader, so the check finds the class file and the template is refused; those deployments are not affected. The exposure is confined to deployments that give wicket-core a class loader which cannot see the application's component classes: wicket-core placed in a servlet container's shared library directory, in an enterprise archive library directory with the application in the web archive, as an application server global module, or as an OSGi bundle, where wicket-core's bundle cannot resolve a class held by an application bundle. Markup shipped by Wicket's own modules, and by any other code sharing a class loader with wicket-core, remains protected. An attacker has to name a component class, and Wicket writes fully qualified class names into the URL of every package resource it renders.

This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.

References

1 sources
lists.apache.org/thread.html/90mlx42q7nkdccdby1ql1ksl4sxy13x6
Vendor advisoryapache

Inside the record

Evidence available

Package identity
Version evidence
Remediation guidance · not supplied
Weakness classification
Additional publishers

Describes the evidence in this view, not whether the product is safe.

Original records

CVE-2026-84172

View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.

cve.new JSON →

Underlying weaknesses

The source’s classification of what caused the vulnerability.

CWE-552 ↗

CWE-552 Files or Directories Accessible to External Parties

apache

Related →
Contributing organizations · 2
apache

Assigning organization

2026-11-01
CISA-ADP

Additional data publisher

2026-11-06

Timeline

All times UTC

  1. Advisory published

    Publication date supplied by the source.

  2. Source updated

    Latest modification date supplied by the source.

  3. Last imported by cve.new

    Latest catalog import, not the date we first saw this advisory.

What changed

Follow changes
  1. CVE · CVE-2026-84172

    Observed 2026-11-06T15:02:00.281Z · upstream updated 2026-11-06T14:43:30.226Z

    Prioritization updated

    before

    []

    after

    [
  {
    "source": "CISA-ADP",
    "type": "SSVC",
    "role": "CISA Coordinator",
    "timestamp": "2026-11-06T14:43:20.008705Z",
    "decisions": [
      {
        "name": "Exploitation",
        "value": "none"
      },
      {
        "name": "Automatable",
        "value": "no"
      },
      {
        "name": "Technical Impact",
        "value": "partial"
      }
    ]
  }
]

Large field values are marked as truncated previews. Original source snapshots remain retained.

Showing up to 50 most recent observed changes.