- NVD says iDocView's /doc/upload endpoint accepts a hardcoded token, "testtoken", letting unauthenticated attackers fetch any URL, including local files, under CVE-2023-54402.
- NVD cites Shadowserver exploitation evidence from March 26, 2024, and published the record on September 30, 2026. It gives no affected versions or fix details.
- Check whether iDocView runs anywhere in your estate, confirm fix status with the vendor, review logs for the endpoint and rotate credentials in exposed configuration files.
Some security failures are not clever. They are a shortcut that shipped. CVE-2023-54402 is one of them. According to the NIST National Vulnerability Database (NVD), iDocView accepts a hardcoded default token as proof of identity. That one decision, made once by the vendor, reaches customers who run an affected version, which the record does not specify.
What NVD says happened
The NVD record describes a server-side request forgery (SSRF) flaw in iDocView's /doc/upload endpoint. A remote attacker with no account can make the server fetch any URL they choose. To get past the login check, the attacker supplies a default token value: "testtoken".
The record was published on September 30, 2026 and last modified on October 1. Its scores come from VulnCheck, which lists the issue under [email protected].
How the attack works
In an SSRF attack, the attacker does not touch the target data directly. They ask the server to do it for them. The server sits inside the company network, so it can reach places an outsider cannot.
Two design choices combine here. First, the authentication check accepts a default value built into the product. Anyone who knows it can pass. Second, the endpoint does not restrict which kinds of address it will fetch.
The NVD record says this includes file:// addresses. Those point at files on the server's own disk rather than at a website. An attacker can therefore ask for operating-system and application configuration files. They can also ask the server to contact internal hosts and services that are not otherwise reachable.
Configuration files often hold the details that open other systems. The NVD record does not say what any attacker actually took. It describes what the flaw permits.
The vector shows why the scores are high. The attack runs over the network, needs low effort, needs no privileges and needs no user to click anything. The scoring rates the impact as high for confidentiality, meaning data exposure. It rates integrity and availability as none.
That scoring covers file disclosure. It does not attempt to price what an attacker might do after reading a configuration file.
The dates raise a question the record doesn't answer
The NVD record says the Shadowserver Foundation first observed exploitation evidence on March 26, 2024. The record itself was published on September 30, 2026. That is about two and a half years later.
The NVD publication date need not be the date the flaw first became public. The record does not say when the vendor, researchers or customers first learned of it. It does not explain the gap, so the gap stays an open question.
The record also does not say whether a fix exists or which versions are affected. A leader reading it cannot tell from the record alone whether a patched release is available.
The references point to a public detection template in the ProjectDiscovery Nuclei repository, a VulnCheck advisory and a blog post. The record does not date them. The listed Nuclei template suggests scanners can already test for this.
The lesson: a default is a decision your customers inherit
This is interpretation, not a claim the record makes. A token named "testtoken" looks like a convenience for developers. Convenience values turn into exposure when they ship unchanged. Buyers inherit a choice they did not make, and the record does not say whether the token can be changed.
Software that uses a shared secret is only as private as the secret. When the secret is the same everywhere, it is no longer a secret.
What to ask your team
Start with inventory. Does anyone in the organisation run iDocView, including inside a vendor's product or a forgotten internal tool? The record gives no further detail on affected versions, so confirm with the vendor.
If it is in use, ask four things. Is the /doc/upload endpoint reachable from the internet? Has the vendor confirmed a fix or a way to remove the default token? Do server logs show requests to that endpoint, especially ones with file:// addresses? Which credentials sit in the configuration files on that host, and could they be rotated?
For procurement, add one question to every software review: which default credentials or tokens ship with the product, and how are they removed? A fixed token is cheap to write and costly to inherit.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
