Safeguard
Application Security•

CWE-613 Insufficient Session Expiration: Tokens That Never Die

Sessions and tokens with no expiry stay valid after theft, logout, or a password change. How CWE-613 happens and the fix MITRE recommends.

Safeguard Security Team
3 min read

CWE-613 uses a definition from the Web Application Security Consortium, quoted by MITRE: insufficient session expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization.

Any product with logins can have it, from web apps to the embedded web interfaces on network and industrial equipment.

How it happens

A session ID or token is issued at login and then never expires, or expires so far in the future it might as well not. Logging out may only delete the browser's copy, while the server keeps honouring the old value.

# Vulnerable pattern: token with no expiry claim
token = jwt.encode({"sub": user.id}, SECRET, algorithm="HS256")

Recent examples in MITRE's record:

  • CVE-2025-46344: a JavaScript SDK did not set an expiration time for JWE tokens related to a session.
  • CVE-2024-8888: the web interface for a power quality analyzer used tokens without an expiration date.
  • CVE-2024-35206: a network traffic analyzer for PROFINET networks did not expire sessions.
  • CVE-2024-27782: an AI/ML monitor for IT operations allowed re-use of old session tokens.

Two of those are libraries or SDKs, which means the missing expiry may be inherited by every application built on them.

What an attacker gains

The consequence is a bypass of the protection mechanism. A session ID taken from a log, a shared computer, a proxy, or a leaked URL keeps working indefinitely, so the attacker gets the victim's access without ever knowing the password.

How to find it

Static analysis (SAST) can find some instances. Practical checks:

  1. Log in, copy the session cookie or token, log out, and replay the value. If it still works, logout is not invalidating server side state.
  2. Decode tokens and look for an expiry claim.
  3. Leave a session idle for longer than your policy and try it again.
  4. Check which SDK or library versions you depend on, since a library default can be the cause. The free dependency scan at gold.safeguard.sh/scan runs in your browser, needs no login, and works on up to 100 dependencies.

How to fix it

MITRE's mitigation is to set session and credential expiration dates. In practice:

  • Give every token an expiry and enforce it on the server.
  • Use a short idle timeout and a hard maximum lifetime.
  • On logout, password change, and privilege change, invalidate the session on the server.
  • Prefer short lived access tokens with a refresh flow that can be revoked.
token = jwt.encode(
    {"sub": user.id, "exp": datetime.now(timezone.utc) + timedelta(minutes=15)},
    SECRET, algorithm="HS256")

Quick check

Does deleting the cookie on logout end the session? Only in that browser. If the server still accepts the old value, an attacker holding a copy can keep using it.

Where can the missing expiry come from? Often from an SDK or library default, so check dependencies as well as your own code.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.