open-wanderer wanderer, CVE-2026-71495: a new CVE scored 10

The bottom line

Anyone running a self-hosted Wanderer instance below 0.20.0 with PUBLIC_PRIVATE_INSTANCE not set to true should update to 0.20.0 now; the fix has been available since 7 July. Start by confirming the version and that setting in your docker-compose or environment file.

Free analysis report · 10 pagesopen-wanderer wanderer, CVE-2026-71495: a new CVE scored 10The same note as a document you can keep or forward: what the sources say, who is affected, and what to do first.Download the analysis report →

At a glance

Does this apply to you?

What it is

The record describes a flaw in the trail download endpoint. An attacker who can reach the server sends a crafted request with any URL in the body; the server fetches it without checking and returns the result. This lets the attacker read from internal services, probe the internal network, or overwhelm internal hosts.

Why it matters

The record scores this 10 out of 10 under CVSS 3.1, with no authentication required and no user interaction, reachable over the network. The weakness is CWE-918. An attacker who can reach the endpoint directs the server to contact internal services; the record names the database on port 8090, the search service on port 7700, and cloud metadata addresses. Our reading is that reaching cloud metadata is particularly useful for credential theft even without a login to the application. The CVSS scope-change flag reflects that the impact extends beyond the application itself to internal infrastructure.

What the vendor's advisory says

We read two pages on github.com. In short:

• The v0.20.0 release notes also describe hardened ActivityPub federation and a fix for an N+1 query in follower fanout (PR #1056). No CVE identifier is given for those changes.
• v0.20.0 has breaking changes: integrations now run as sandboxed WASM plugins; trail categories have been reworked. The release notes say operators must update docker-compose.yml for the new /data/plugins folder and install plugins manually after upgrading.

Exposure by situation

These priorities are our judgement from what the sources say about who can use the flaw and how. They are not vendor ratings.

Things people will get wrong

• Setting PUBLIC_PRIVATE_INSTANCE=true is enough without upgrading. The record identifies 0.20.0 as the fix. The description ties the unauthenticated access to that flag being unset, but the record does not say the flag alone closes the flaw; only 0.20.0 is confirmed.
• Only internet-facing instances are at risk. Any user or system that can reach the Wanderer server can send the crafted request. An internal user or a compromised device on the same network can exploit this without internet access.

How we would triage it

This is our judgement.

The commands only read: they print a version or list what is installed. They come from general knowledge of this kind of product, not from the sources, so check them against the vendor's page before you run them. Words in capitals are for you to fill in.

Step 1: Find the version you run

• Check your docker-compose.yml or the running container image tag for the current version; any version below 0.20.0 is in the affected range.
• If you are unsure which tag is in use, check the compose file for the image line in the wanderer service definition.

docker ps --format '{{.Image}}' | grep wanderer

Step 2: Check the PUBLIC_PRIVATE_INSTANCE setting

• Review your environment file or docker-compose.yml for PUBLIC_PRIVATE_INSTANCE; if absent or not set to true, the download endpoint accepts unauthenticated requests and exposure is highest.
• The record names no workaround other than the 0.20.0 update; restricting network access to the server while preparing the update reduces exposure temporarily.

Step 3: Update to 0.20.0

• Before restarting, update docker-compose.yml to map the new /data/plugins folder in the db service volumes section, as the v0.20.0 release notes require for self-hosted instances.
• Pull the 0.20.0 image, restart the service, and install any plugins following the release notes documentation.

Step 4: Confirm the update is in place

• After restarting, confirm the running container image is tagged 0.20.0 using the command below.
• Verify that PUBLIC_PRIVATE_INSTANCE is set correctly in the updated configuration.

To close it, read the version from the product itself, not from an old inventory, and save the output with the date. If you cannot update today, write down who owns it, the new date, and what limits exposure until then.

Send this to your IT provider

Copy it, change the names and dates, and send it. It is a draft for you to check, not a template tested with any provider.

We run a self-hosted Wanderer trail database. CVE-2026-71495 describes an unauthenticated server-side request forgery in versions below 0.20.0, which allows anyone who can reach the server to direct it to fetch internal services or cloud metadata addresses. The fix is in version 0.20.0, released 7 July. Could you please confirm: which version of Wanderer we are running; whether PUBLIC_PRIVATE_INSTANCE is set to true in our configuration; and whether the server is reachable from outside our network. If we are below 0.20.0, we would like written confirmation that the update to 0.20.0 has been applied and completed, by [DATE].

The weakness behind it

The record classes this as CWE-918.

• CWE-918 →What this kind of mistake is, and which exploited vulnerabilities share it.

Likely ATT&CK mapping

MITRE ATT&CK is a public catalogue of the steps attackers take, from getting in to causing damage. No source has mapped this flaw to it yet, so the steps below are our prediction from what the record says the flaw allows. They are not MITRE's, the vendor's or CISA's, and an attacker may do other things.

How to use this: ask your IT provider which control or log would show each step, for example whether sign-in attempts from the internet are recorded. If nobody can answer, that is the gap to close first.

MITRE ATT&CK® is a registered trademark of The MITRE Corporation. Technique names are MITRE's.

The sources, in their words

The CVE record:

Wanderer is a self-hosted trail database for saving and sharing adventures. Prior to 0.20.0, when PUBLIC_PRIVATE_INSTANCE is not set to true, the unauthenticated POST /api/v1/trail/download handler passes the attacker-controlled JSON url field directly to event.fetch() and returns the fetched response. This allows requests to internal services such as db:8090 and search:7700, cloud metadata addresses, and other network destinations, exposing returned data and permitting internal network reconnaissance or denial of service. This issue is fixed in version 0.20.0.

Versions of open-wanderer wanderer the record lists as affected:

• < 0.20.0

The record gives no version ranges. Use the vendor's advisory for the affected versions.

Check your own project

If you build software, you can compare what a project declares with this CVE from a terminal. The tool reads requirements files, package.json, Maven, Gradle, Cargo, CMake and Dockerfile files, runs nothing, and only the CVE id leaves your machine. Naming the CVEs needs no key.

lattice-scan project . --cve CVE-2026-71495

Each row says in-range, outside-range, undetermined or lead, with the file and line. That is evidence about what a manifest declares, not about what runs, and a person decides. The verdicts, the CSV columns and a pipeline recipe are in the guide.

Check the servers you run

The same id can be checked against a host. Run this on the machine itself, not on the laptop that deploys to it: it reads installed packages (dpkg, rpm or apk), snaps, the hardware (maker, model, firmware), the running container images with their operating system and packages, and the kernel version, compares them on the spot, and only the CVE ids leave the machine; the inventory stays on it, in ~/.lattice-scan. Naming the CVEs needs no key. Do it on each server after a deployment, and again when a new entry lands.

lattice-scan --cve CVE-2026-71495

A match is a candidate for a person to confirm, not a finding. A distribution can fix a CVE under an unchanged version number, so a match is a candidate; on Debian-family hosts the report also shows whether the package's own changelog names the CVE. By default it opens the images your containers are running and reads their operating system and package list; a deep scan (--deep, a few minutes) opens every local image and the Python, Node, Java and Ruby packages inside them; for what an image declares, use the project check on its Dockerfile.

Guide: namiq.io/lattice/guides/choose-your-channel. MCP server (io.namiq/lattice in the MCP registry): namiq.io/lattice. Package: pypi.org/project/lattice-scan, or namiq.io/apt.

• Which way into Lattice fits your job →The command line, the Claude skill or the MCP server: what each needs, what works without a key and how to read the result.
• Lattice, the MCP server →The public graph the command reads, for AI agents over MCP.
• Install and connect →The signed apt repository, the fingerprint, and the connection commands for each client.

What we do not know yet

• Whether setting PUBLIC_PRIVATE_INSTANCE=true fully prevents unauthenticated access to the download endpoint in versions below 0.20.0, or only partially reduces exposure.
• Whether the cloud metadata addresses the SSRF can reach include credential-serving endpoints on the infrastructure a given deployment runs on.
• The advisory identifier GHSA-7vqq-mjjr-h9j5 is named in the v0.20.0 release notes; details beyond what the CVE record states are not reproduced in the sources provided.
• The GitHub source text says 'No CWEs' while the structured data lists CWE-918; the reason for this discrepancy is not stated in the sources.
• Exploitation is not recorded. That is not the same as none.
• This is a new record: scores, versions and wording can change in the first days, and they are as at 6 November 2026. We read the vendor pages listed under Sources; nothing here has been tested.
• The sections headed "The bottom line", "Does this apply to you?", "What it is", "Why it matters", "Exposure by situation", "Things people will get wrong", "Likely ATT&CK mapping", "How we would triage it" and "Send this to your IT provider" are our interpretation of the sources, not a statement by CISA or the vendor.

• The day's CVE highlight →The three new records we picked that day, and how we chose them.
• Today's mission →Every exploited vulnerability from the last seven days, in the order their deadlines fall.