What Is a Predictable Identifier Vulnerability?

A predictable identifier vulnerability is a flaw where software generates a value that should be hard to guess, such as a session token, upload file name, reset code or object ID, from a source an attacker can predict. MITRE tracks the class as CWE-340. On its own it often scores low, but it turns "the attacker can write a file somewhere" into "the attacker knows exactly where it is," which is often the missing piece in an exploit chain.

What is a predictable identifier vulnerability?

It is a weakness where a value meant to be unguessable can be guessed or calculated. Anything that relies on that value staying secret, such as a session, a temporary file or a one-time link, can then be reached by someone who was never given it.

Common examples:

• Sequential IDs. Invoice 1001 is followed by invoice 1002. If access control relies on the number being unknown, every record is one guess away.
• Time-based values. A file named from a timestamp, or a token seeded from the clock, narrows the search to a few thousand candidates.
• Weak random number generators. General-purpose generators are fast and statistically even, but their output can be reconstructed from a few observed values. Security tokens need a cryptographically secure generator.
• Fixed or derived paths. A temporary file written to the same directory under a name built from the user ID or process ID is a known location, not a secret one.

Why does a low CVSS score understate it?

A predictable identifier bug usually needs another weakness to cause damage, so CVSS rates it on its own and gives it a modest score. In a chain, it supplies certainty: the attacker no longer has to guess where a file landed or which token is valid.

Ivanti Connect Secure is a current example. CVE-2026-118527, rated CVSS 4.3 by Ivanti, lets a remote authenticated attacker upload files with attacker-controlled content to a known location on disk. CISA added it to the Known Exploited Vulnerabilities catalog on October 30, 2026, noting it can be chained with an authentication bypass (CVE-2026-104935) and a privilege escalation (CVE-2026-111357). Volexity documented that chain reaching unauthenticated root on a VPN appliance. The full story is in our report on the Ivanti Connect Secure CVE-2026-111357 fix.

The authentication requirement on CVE-2026-118527 sounds like a barrier. In a chain that starts with an authentication bypass, it is not one. The same logic applies to any "authenticated" or "local" bug that sits behind an internet-facing login page.

How do attackers use a predictable value?

They use it to find or reach something the software assumed was hidden. Typical outcomes are reading another user's record, hijacking a session, or locating an uploaded file so another flaw can execute or include it.

For defenders, the useful question is what the identifier protects. A predictable ID on a public blog post is harmless. The same weakness on a password reset token, an upload staging path on an appliance, or a session cookie is a direct path to compromise.

Where predictable identifiers show up

• Upload handlers. Files staged to a fixed temporary directory with guessable names. If anything else on the system can be tricked into reading or running files from that directory, the guessable name completes the attack.
• Session and API tokens. Tokens built from user IDs, timestamps or weak generators.
• Password reset and invitation links. Short numeric codes, or codes that do not expire.
• Object references in APIs. Sequential record IDs without a per-request authorization check. This overlaps with insecure direct object reference (IDOR) bugs.
• Embedded and appliance firmware. Devices often have limited entropy at boot and older code paths, which makes weak generation more likely.

How do you reduce the risk in software you run?

You cannot fix the generator in a vendor's appliance, but you can control what it is exposed to and how fast you patch it.

1. Patch chained low scores as part of the chain. When an advisory lists several CVEs together, or KEV says they can be chained, schedule them at the priority of the most severe one. The site's guide on why vulnerability chaining beats CVSS scores in triage covers how to set that rule.
2. Limit who reaches pre-authentication pages. Restrict management interfaces to admin networks. For user-facing portals that must stay public, put them behind a reverse proxy or WAF where you can log and filter requests.
3. Watch the staging locations. Unexpected files or processes in temporary directories on appliances are a common sign of exploitation. For Ivanti specifically, see how to detect Ivanti Connect Secure exploitation.
4. Track the full fix. Vendors sometimes patch the headline CVE first and the supporting flaws later, as Ivanti did here. Our guide to why partial security patches mean upgrading twice explains how to keep those tickets open.

How do developers prevent it?

Developers prevent it by generating every security-relevant value with a cryptographically secure random number generator and by never letting secrecy stand in for authorization.

In practice that means:

• Use the platform's secure generator for tokens and file names: secrets in Python, crypto.randomBytes or crypto.randomUUID in Node.js, RandomNumberGenerator in .NET.
• Give tokens enough length (128 bits or more) and an expiry.
• Store uploads outside any executable path, rename them to random values, and validate content before writing them to disk, not after.
• Check authorization on every object request, even when the ID is random. Random IDs make guessing harder; they do not replace the permission check.