vulnerabilityAlerts PRs not created

[LecrisUT]

How are you running Renovate?

A Mend.io-hosted app

Which platform you running Renovate on?

Other (please specify)

Which version of Renovate are you using?

Self-hosted github app (42.99.0)

Please tell us more about your question or problem

Vulnerabilities are picked up from github security, they show up in the log, but it does not produce the security PRs

Logs (if relevant)

Logs

Full log: https://github.com/teemtee/tmt/actions/runs/36691379243

DEBUG: Repository config (repository=teemtee/tmt)
       "fileName": ".github/renovate.json",
       "config": {
         "$schema": "https://docs.renovatebot.com/renovate-schema.json",
         "extends": [
           "config:recommended",
           ":enablePreCommit",
           ":semanticCommitsDisabled"
         ],
         "separateMajorMinor": false,
         "configMigration": true,
         "labels": ["renovate"],
         "packageRules": [
           {
             "description": "Group all GitHub Actions updates into a single PR",
             "groupName": "GitHub Actions",
             "matchManagers": ["github-actions"]
           },
           {
             "description": "Python upgrade is a false-positive. We have to pull in both 3.x and 3.9 for pre-commit.",
             "matchManagers": ["github-actions"],
             "matchDepNames": ["python"],
             "matchFileNames": ["pre-commit.yml"],
             "enabled": false
           },
           {
             "description": "Disabled because it breaks folder structure, and need to be more selective.",
             "groupName": "Container Images",
             "matchDatasources": ["docker"],
             "enabled": false
           },
           {
             "description": "Group Pre-commit dependencies together",
             "groupName": "Pre-commit Dependencies",
             "matchManagers": ["pre-commit"]
           },
           {
             "description": "Python dependencies with lockfile",
             "groupName": "Locked dependencies",
             "matchManagers": ["pep621"]
           },
           {
             "description": "Group documentation dependencies together",
             "groupName": "Documentation Dependencies",
             "matchManagers": ["pep621"],
             "matchDepTypes": ["project.optional-dependencies"],
             "enabled": true,
             "matchJsonata": ["managerData.depGroup = 'docs'"]
           }
         ],
         "lockFileMaintenance": {"enabled": true, "groupName": "Locked dependencies"}
       }
DEBUG: migrateAndValidate() (repository=teemtee/tmt)
DEBUG: No config migration necessary (repository=teemtee/tmt)
DEBUG: Post-massage config (repository=teemtee/tmt)
       "config": {
         "$schema": "https://docs.renovatebot.com/renovate-schema.json",
         "extends": [
           "config:recommended",
           ":enablePreCommit",
           ":semanticCommitsDisabled"
         ],
         "separateMajorMinor": false,
         "configMigration": true,
         "labels": ["renovate"],
         "packageRules": [
           {
             "description": ["Group all GitHub Actions updates into a single PR"],
             "groupName": "GitHub Actions",
             "matchManagers": ["github-actions"]
           },
           {
             "description": [
               "Python upgrade is a false-positive. We have to pull in both 3.x and 3.9 for pre-commit."
             ],
             "matchManagers": ["github-actions"],
             "matchDepNames": ["python"],
             "matchFileNames": ["pre-commit.yml"],
             "enabled": false
           },
           {
             "description": [
               "Disabled because it breaks folder structure, and need to be more selective."
             ],
             "groupName": "Container Images",
             "matchDatasources": ["docker"],
             "enabled": false
           },
           {
             "description": ["Group Pre-commit dependencies together"],
             "groupName": "Pre-commit Dependencies",
             "matchManagers": ["pre-commit"]
           },
           {
             "description": ["Python dependencies with lockfile"],
             "groupName": "Locked dependencies",
             "matchManagers": ["pep621"]
           },
           {
             "description": ["Group documentation dependencies together"],
             "groupName": "Documentation Dependencies",
             "matchManagers": ["pep621"],
             "matchDepTypes": ["project.optional-dependencies"],
             "enabled": true,
             "matchJsonata": ["managerData.depGroup = 'docs'"]
           }
         ],
         "lockFileMaintenance": {"enabled": true, "groupName": "Locked dependencies"}
       }
DEBUG: Found repo ignorePaths (repository=teemtee/tmt)
       "ignorePaths": [
         "**/node_modules/**",
         "**/bower_components/**",
         "**/vendor/**",
         "**/examples/**",
         "**/__tests__/**",
         "**/test/**",
         "**/tests/**",
         "**/__fixtures__/**"
       ]
DEBUG: http cache: saving https://api.github.com/repos/teemtee/tmt/dependabot/alerts?state=open&direction=asc&per_page=100 (etag=W/"d5401c1c829f52691de843f334db5ccd369587b128ec91d7860f17a753f3dc83", lastModified=Tue, 29 Sep 2026 20:27:37 GMT) (repository=teemtee/tmt)
DEBUG: GitHub vulnerability details (repository=teemtee/tmt)
       "alerts": {
         "pip/setuptools": {"< 83.0.0": "83.0.0"},
         "pip/oauthlib": {">= 0.6.1, <= 3.3.1": "4.0.0", ">= 3.0.0, < 4.0.0": "4.0.0"}
       }
DEBUG: alert package rules (repository=teemtee/tmt)
       "alertPackageRules": [
         {
           "matchDatasources": ["pypi"],
           "matchPackageNames": ["setuptools"],
           "matchFileNames": ["uv.lock"],
           "matchCurrentVersion": "< 83.0.0",
           "vulnerabilityFixVersion": "83.0.0",
           "prBodyNotes": [
             "### GitHub Vulnerability Alerts",
             "#### [CVE-2026-59890](https://github.com/pypa/setuptools/security/advisories/GHSA-h35f-9h28-mq5c)\n\n## Summary\n\nWhen building a source distribution (`python -m build --sdist` / `setup.py sdist`), setuptools' `FileList` applies `MANIFEST.in` directives (`exclude`, `global-exclude`, `recursive-exclude`, `prune`) by matching a compiled glob against on-disk file names **byte-for-byte, with no Unicode normalization**. On normalization-preserving filesystems (notably macOS APFS and HFS+), a file written in NFD and a `MANIFEST.in` rule written in NFC refer to the same file but are byte-distinct, so the exclusion silently fails to match. A file the maintainer intended to exclude is then packed into the `.tar.gz` and, if published, uploaded to the public, immutable PyPI index.\n\n## Details\n\nFile names in `FileList.files` come from `os.walk` (`setuptools/_distutils/filelist.py`, `_find_all_simple`), so on APFS a file written NFD is offered to the matcher in NFD, while the `MANIFEST.in` pattern carries the author's editor form (typically NFC). The matching path performs no canonicalization:\n\n```python\n\n# setuptools/command/egg_info.py  (FileList.global_exclude)\ndef global_exclude(self, pattern):\n    match = translate_pattern(os.path.join('**', pattern))   # fnmatch.translate -> regex, no NFC/NFD\n    return self._remove_files(match.match)                   # byte-level regex over raw os.walk names\n```\n\nA rule written NFC (`café` = `63 61 66 c3 a9`) does not match an on-disk name written NFD (`café` = `63 61 66 65 cc 81`), even though the filesystem treats the two as one file.\n\nA `unicodedata.normalize('NFD', ...)` helper exists in `setuptools/unicode_utils.py` (`decompose()`), but it is **never called in the manifest matching path**, so neither the pattern nor the walked path is normalized before matching. The only normalization in this area, `EggInfoCommand._manifest_normalize`, uses `filesys_decode` (bytes→str decode only, no NFC/NFD) and runs when writing `SOURCES.txt`, after matching has already occurred.\n\n## Impact\n\n`MANIFEST.in` exclusions are the documented mechanism maintainers use to keep secrets, local configs, and private fixtures out of the published sdist. A non-ASCII excluded file may be published to the public, immutable PyPI index despite the rule — an irreversible disclosure with no visual cue (NFC and NFD forms render identically). Exposure is filesystem-dependent and most relevant on macOS APFS/HFS+, where many maintainers build and publish. Pure-ASCII rules are unaffected.\n\n## Proof of concept\n\nWith a project containing `MANIFEST.in`:\n\n```\nglobal-include *.txt *.json\nglobal-exclude secret_café.txt    # rule saved NFC\n```\n\nand an on-disk file `secret_café.txt` written in NFD, `python -m build --sdist` packs the secret file into the resulting `.tar.gz`, while an ASCII control file excluded by the same directive is correctly dropped — isolating the bypass to the NFC-pattern vs. NFD-name mismatch. Reproduced on macOS APFS with setuptools 82.0.1.\n\n## Remediation\n\nNormalize both the walked path and each `MANIFEST.in` pattern to a single canonical form before matching, in both `setuptools/command/egg_info.py` (`FileList`) and the vendored `setuptools/_distutils/filelist.py`. For an exclusion list, err toward excluding more, and document that `MANIFEST.in` matching is normalization-insensitive on macOS.\n\n## Credit\n\nReported by Tomas Illuminati. Coordinated via CERT/CC VINCE VU#604762."
           ],
           "isVulnerabilityAlert": true,
           "force": {
             "groupName": null,
             "schedule": [],
             "dependencyDashboardApproval": false,
             "minimumReleaseAge": null,
             "rangeStrategy": "update-lockfile",
             "commitMessageSuffix": "[SECURITY]",
             "branchTopic": "{{{datasource}}}-{{{depNameSanitized}}}-vulnerability",
             "prCreation": "immediate",
             "vulnerabilityFixStrategy": "lowest"
           }
         },
         {
           "matchDatasources": ["pypi"],
           "matchPackageNames": ["oauthlib"],
           "matchFileNames": ["uv.lock"],
           "matchCurrentVersion": "< 4.0.0",
           "vulnerabilityFixVersion": "4.0.0",
           "prBodyNotes": [
             "### GitHub Vulnerability Alerts",
             "#### [CVE-2026-49264](https://github.com/oauthlib/oauthlib/security/advisories/GHSA-hj66-6f7g-4r5v)\n\n### Summary\n\nWhen `enable_jsonp=True`, oauthlib's `RevocationEndpoint` reflects the user-supplied `callback` parameter directly into JavaScript response bodies on both success and error paths without validating that it is a legal JSONP callback name. This allows arbitrary JavaScript response generation instead of a restricted function call, making the documented JSONP revocation feature unsafe for browser-based JSONP consumption when attackers can influence `callback`.\n\n### Details\n\nThe issue is in `oauthlib/oauth2/rfc6749/endpoints/revocation.py`.\n\nWhen `enable_jsonp=True` is passed to the `RevocationEndpoint` constructor, two code paths wrap the response body using the user-supplied `request.callback` parameter:\n\n```python\n\n# Error response path (line 72-73):\nif self.enable_jsonp and request.callback:\n    response_body = '{}({});'.format(request.callback, response_body)\n\n# Success response path (line 81-82):\nif self.enable_jsonp and request.callback:\n    response_body = request.callback + '();'\n```\n\nThe `request.callback` value comes from HTTP request parameters, either the query string or POST body, via the `Request` class in `oauthlib/common.py` (lines 394-395), which merges query and body parameters into `_params`. Any value the client sends as `callback` is used verbatim.\n\nThere is no validation of any kind on the callback parameter:\n- No check that it is a valid JavaScript identifier\n- No whitelist of allowed characters\n- No escaping or sanitization\n\nA safe JSONP implementation must validate that the callback is a legal JavaScript function name (e.g., matching `^[a-zA-Z_$][a-zA-Z0-9_$.]*$`). Without this, the attacker controls the JavaScript code returned in the response body. This is the standard mitigation used by jQuery, Express.js, Google APIs, and other major JSONP implementations.\n\n**How the injection works:**\n\nAn attacker sends a revocation request with a crafted callback value:\n\n```\nPOST /revoke HTTP/1.1\nContent-Type: application/x-www-form-urlencoded\n\ntoken=anything&callback=alert(document.cookie)//\n```\n\nThe server responds with:\n\n```\nalert(document.cookie)//({\"error\": \"invalid_client\"});\n```\n\nThis is syntactically valid JavaScript. `alert(document.cookie)` executes as a statement, and `//` comments out the rest of the line. The attacker has full control over the code that appears before the `//`.\n\n**Execution context and attack surface:**\n\nJSONP works by having a browser load a remote script via `<script src=\"...\">`. The loaded script executes in the origin of the **including page**, not the remote server. This means a `<script src=\"https://auth.example.com/revoke?token=x&callback=payload\">` tag on `evil.com` would execute the payload in `evil.com`'s context, not the auth server's context.\n\nThe impact comes from client-side integrations that consume this endpoint as trusted JSONP. If a legitimate OAuth client includes `<script src>` pointed at the revocation endpoint and an attacker can influence the callback value (e.g., via query parameter injection, a reflected value, or a man-in-the-middle downgrade), the attacker controls what code runs in the client application's origin. The authorization server becomes a source of attacker-controlled JavaScript that client applications trust and execute.\n\nNote: the `enable_jsonp` parameter defaults to `False`, so only deployments that explicitly opt in are affected. However, this is a supported, documented library feature, not a debug flag. The client-side library includes `prepare_token_revocation_request()` with an explicit `callback` parameter (`oauthlib/oauth2/rfc6749/parameters.py`, line 174), and the documentation shows JSONP revocation as a use case (`oauthlib/oauth2/rfc6749/clients/base.py`, lines 351-358). The existing test suite tests JSONP callback reflection with a benign value (`test_revocation_endpoint.py`, lines 91-101) but does not test for injection. Deployments that enable JSONP typically do so to support older browsers or cross-origin revocation from JavaScript clients, these are exactly the environments most sensitive to script injection.\n\n### PoC\n\n**Requirements:** Python 3.x with oauthlib installed (`pip install oauthlib`).\n\n```python\nfrom oauthlib.oauth2.rfc6749.endpoints.revocation import RevocationEndpoint\nfrom oauthlib.oauth2.rfc6749.request_validator import RequestValidator\n\n\nclass FailValidator(RequestValidator):\n    \"\"\"Auth fails -> triggers error response path (lines 72-73).\"\"\"\n    def client_authentication_required(self, request, *a, **kw): return True\n    def authenticate_client(self, request, *a, **kw): return False\n    def authenticate_client_id(self, client_id, request, *a, **kw): return False\n\n\nclass PassValidator(RequestValidator):\n    \"\"\"Auth passes -> triggers success response path (lines 81-82).\"\"\"\n    def client_authentication_required(self, request, *a, **kw): return False\n    def authenticate_client_id(self, client_id, request, *a, **kw): return True\n    def revoke_token(self, token, token_type_hint, request, *a, **kw): pass\n\n\npayloads = [\n    \"alert(document.cookie)//\",\n    \"window.location='https://evil.com/'//\",\n    \"eval('malicious')//\",\n]\n\n# --- Error path (401) ---\nprint(\"Error path (enable_jsonp=True, auth fails):\")\nep_fail = RevocationEndpoint(FailValidator(), enable_jsonp=True)\nfor p in payloads:\n    h, body, status = ep_fail.create_revocation_response(\n        \"[https://auth.example.com/revoke\](https://auth.example.com/revoke/)", http_method=\"POST\",\n        body=f\"token=x&callback={p}\")\n    assert p in body, \"Payload not reflected\"\n    print(f\"  [{status}] Content-Type: {h.get('Content-Type','(none)')}  Body: {body}\")\n\n# --- Success path (200) ---\nprint(\"\\nSuccess path (enable_jsonp=True, revocation succeeds):\")\nep_pass = RevocationEndpoint(PassValidator(), enable_jsonp=True)\nfor p in payloads:\n    h, body, status = ep_pass.create_revocation_response(\n        \"[https://auth.example.com/revoke\](https://auth.example.com/revoke/)", http_method=\"POST\",\n        body=f\"token=x&callback={p}\")\n    assert p in body, \"Payload not reflected\"\n    print(f\"  [{status}] Content-Type: {h.get('Content-Type','(none)')}  Body: {body}\")\n\n# --- Control (default: enable_jsonp=False) ---\nprint(\"\\nControl (enable_jsonp=False, default):\")\nep_safe = RevocationEndpoint(FailValidator(), enable_jsonp=False)\n_, body, status = ep_safe.create_revocation_response(\n    \"[https://auth.example.com/revoke\](https://auth.example.com/revoke/)", http_method=\"POST\",\n    body=\"token=x&callback=alert(1)//\")\nassert \"alert\" not in body, \"Payload should not be present\"\nprint(f\"  [{status}] {body}\")\nprint(\"\\nAll assertions passed.\")\n```\n\n**Expected output:**\n\n```\nError path (enable_jsonp=True, auth fails):\n  [401] Content-Type: application/json  Body: alert(document.cookie)//({\"error\": \"invalid_client\"});\n  [401] Content-Type: application/json  Body: window.location='https://evil.com/'//({\"error\": \"invalid_client\"});\n  [401] Content-Type: application/json  Body: eval('malicious')//({\"error\": \"invalid_client\"});\n\nSuccess path (enable_jsonp=True, revocation succeeds):\n  [200] Content-Type: (none)  Body: alert(document.cookie)//();\n  [200] Content-Type: (none)  Body: window.location='https://evil.com/'//();\n  [200] Content-Type: (none)  Body: eval('malicious')//();\n\nControl (enable_jsonp=False, default):\n  [401] {\"error\": \"invalid_client\"}\n\nAll assertions passed.\n```\n\nBoth paths reflect the attacker's payload verbatim into the response body.\n\n### Impact\n\nAny oauthlib-based authorization server that enables JSONP on the revocation endpoint (`enable_jsonp=True`) returns attacker-controlled JavaScript in its response body.\n\nAny page or application that loads this endpoint's response as JSONP and exposes attacker influence over the `callback` parameter will execute attacker-controlled code in its own origin. If a legitimate OAuth client uses JSONP revocation (as documented by oauthlib's client-side API) and an attacker can influence the callback value, the attacker controls what code runs in the client application, including access to the client page's DOM and any data normally accessible to scripts running in that origin.\n\nThe JSONP feature is intended for legacy cross-origin browser support. Deployments that need it are typically JavaScript-heavy clients, exactly the environment most sensitive to script injection.\n\n**Affected versions:** oauthlib >= 0.6.1 through 3.3.1 (current) and master. The unsanitized callback has been present since the revocation endpoint was first introduced in 2013 (commit `da775de`). The `enable_jsonp` gate was added in 2014 (commit `b85f89a`) but no validation of the callback value was ever added.\n\n### Suggested fix\n\nValidate the `callback` parameter against a strict pattern for legal JavaScript identifiers before using it in the response. Reject or ignore values that do not match:\n\n```python\nimport re\n\n# Only allow safe JSONP callback names: valid JS identifiers, optionally dot-separated\nJSONP_CALLBACK_PATTERN = re.compile(r'^[a-zA-Z_$][a-zA-Z0-9_$]*(\\.[a-zA-Z_$][a-zA-Z0-9_$]*)*$')\n\n# In create_revocation_response(), before using request.callback:\nif self.enable_jsonp and request.callback:\n    if not JSONP_CALLBACK_PATTERN.match(request.callback):\n        request.callback = None\n```\n\nThis is the standard mitigation for JSONP callback injection and is the approach used by jQuery, Express.js, and Google APIs. It ensures only syntactically valid function names like `package.hello_world` are accepted, while blocking payloads like `alert(document.cookie)//`.\n\nAs a secondary hardening measure, when JSONP is enabled, the response should set `Content-Type: application/javascript` (not `application/json` or empty) to ensure correct browser handling. Currently the success path returns no Content-Type at all, and the error path returns `application/json`.\n\nAlternatively, if JSONP is no longer considered a necessary feature, consider deprecating and removing the `enable_jsonp` option entirely. CORS is now supported by all modern browsers and is the standard mechanism for cross-origin API access.",
             "#### [CVE-2026-49265](https://github.com/oauthlib/oauthlib/security/advisories/GHSA-xpv3-w29h-x7cv)\n\n## Summary\n\nA timing side-channel vulnerability exists in the PKCE (RFC 7636) implementation \nof the Authorization Code Grant flow. The `code_challenge_method_plain` function \nuses Python's standard `==` operator for string comparison instead of a \nconstant-time comparison function, potentially allowing timing-based attacks.\n\n## Affected Component\n\n- File: `oauthlib/oauth2/rfc6749/grant_types/authorization_code.py`\n- Functions: `code_challenge_method_plain`, `code_challenge_method_s256`\n- Vulnerability Type: CWE-208 (Observable Timing Discrepancy)\n\n## Technical Details\n\nPython's `==` operator uses short-circuit evaluation when comparing strings:\n1. Returns `False` immediately if lengths differ\n2. Compares characters left-to-right, stopping at first mismatch\n\nThis means comparison time varies linearly with the length of the common prefix \nbetween the attacker-supplied verifier and the stored challenge, creating a \nmeasurable timing oracle.\n\n## Proof of Concept\n\nTested locally against oauthlib source (network jitter eliminated to isolate \npure Python execution time):\n\n| Input | Result | Time (10M iterations) |\n|---|---|---|\n| Wrong first char (`B` + `A`*49) | Fast reject | 0.34106s |\n| 49 chars correct (`A`*49 + `B`) | Deep compare | 0.37847s |\n| **Difference** | | **0.03741s** |\n\nThe ~37ms delta over 10M iterations corresponds to nanosecond-level differences \nper call, which are statistically exploitable under controlled conditions.\n\n## Attack Scenario\n\n1. Attacker intercepts `authorization_code` via Custom URI Scheme Hijacking\n2. PKCE blocks token request — attacker lacks `code_verifier`\n3. Attacker sends repeated requests to `/token` endpoint measuring response times\n4. Using timing oracle, attacker recovers `code_verifier` character by character\n5. Attacker obtains Access Token → Account Takeover\n\n> **Note:** Practical exploitability is limited due to the single-use nature of \n> authorization codes and real-world network noise. However, the vulnerable \n> pattern should be corrected as a defense-in-depth measure.\n\n## Recommended Fix\n\nReplace `==` with `hmac.compare_digest()` for constant-time comparison:\n\ncr: Elvin Latifli"
           ],
           "isVulnerabilityAlert": true,
           "force": {
             "groupName": null,
             "schedule": [],
             "dependencyDashboardApproval": false,
             "minimumReleaseAge": null,
             "rangeStrategy": "update-lockfile",
             "commitMessageSuffix": "[SECURITY]",
             "branchTopic": "{{{datasource}}}-{{{depNameSanitized}}}-vulnerability",
             "prCreation": "immediate",
             "vulnerabilityFixStrategy": "lowest"
           }
         }
       ]
DEBUG: findIssue(Dependency Dashboard) (repository=teemtee/tmt)
DEBUG: Found issue 4820 (repository=teemtee/tmt)
DEBUG: http cache: saving https://api.github.com/repos/teemtee/tmt/issues/4820 (etag=W/"7c635edd6a4c0e8ff77a978829bd59dc92463c4fbe126457fc73aa0c463f61ce", lastModified=Wed, 30 Sep 2026 09:24:40 GMT) (repository=teemtee/tmt)
DEBUG: Issues cache: Updating issue 4820 in cache (repository=teemtee/tmt)
DEBUG: No baseBranches (repository=teemtee/tmt)

[RahulGautamSingh]

Transitive dependencies are not remediated individually.

Renovate does pick up both alerts (you can see the alertPackageRules in your log), but setuptools and oauthlib are not declared in your pyproject.toml. They only exist in uv.lock as transitive dependencies (oauthlib via requests-oauthlib, setuptools via copr, mrack and pbr).

Renovate only creates vulnerability PRs for dependencies it extracts from the package file, so the alert rules have nothing to match, and no PR is created.

[RahulGautamSingh]

We used to support it but don't anymore because there was many issues in it's implementation and maintenance became difficult.

If you think, there's a simple less hassle approach you can create a Suggest Feature discussion and we can discuss the details there.

[LecrisUT]

My only thought would be uv lock --upgrade-package but I assume that was the first thing tried that did not pan out in the end. And to be fair dependabot's change does not look better either (does not account for python version limits I believe).

[LecrisUT]

Maybe the only other idea would be to highlight them during the lockfile maintenance?

[RahulGautamSingh]

What do you mean by highlight?

[LecrisUT]

Just listing them in the description with maybe a link to the security entry.