Dependency Alert Triage Report - netbox - 2026-08-16

Executive Summary

Nothing needs fixing today, and no verdict rests on evidence a person still has to resolve. Two alerts are scheduled for a planned fix in the web tier, under the policy's 60-day Moderate window. The remaining 20 of 22 context-specific verdicts (91%) are recommended for deferral, with the evidence below.

All 11 open alerts were retrieved and the count verified. Each finding's reachability was analyzed against this project's own source and its vendored dependency source, in both execution contexts this project declares. Exploitation evidence came from KEV (the CISA/VulnCheck catalog of vulnerabilities with confirmed exploitation in the wild) and EPSS (a daily model score estimating each vulnerability's probability of exploitation in the next 30 days, read as a percentile against all scored CVEs).

Each alert was scored in both execution contexts NetBox ships as systemd units, one verdict per context, so 11 alerts produce 22 verdicts. The two standing answers:

• How many findings are exploitable and reachable in production right now? Zero. No alert in this set is both in KEV and reachable, and none carries an EPSS score anywhere near the top-1% line.
• How much noise did scoring remove? 20 of 22 scored verdicts (91%) are recommended for deferral as not reachable or not exploitable here. Focus can be directed elsewhere.

The reachability and exploitability analysis retired 1,260 of 1,760 inherent NIST risk points (72%), safely deferred 20 of 22 verdicts, and moved 20 verdicts from a High inherent band to a Low residual band.

Recommendation: plan the idna upgrade for the web tier, and treat the nine PyJWT alerts as deferrable on the evidence in the DEFER section.

FIX_TODAY / REVIEW: act now or resolve the unknown

None. Nothing requires immediate action, and no verdict rests on unresolved evidence.

SCHEDULE: fix on a planned horizon

One advisory is scheduled, and it is scheduled because a call path was traced, not because a score looked high. idna.encode() runs on a hostname an authenticated NetBox user chooses, in the gunicorn web process. The vulnerable code is present in the installed version: vendor/idna/core.py:333 runs the expensive per-codepoint validation before the length rejection at :336. Neither CVE is in KEV, and the EPSS percentile is 0.34 against a top-1% threat line, so the urgency comes from the traced path and the asset, not from exploitation evidence. The nearest deadline is 60 calendar days from the date the alert was opened, a date this run did not receive. Entries are ordered by SLA expiry, soonest first, with residual composite descending as the tiebreaker.

CVE-2026-45409 — a denial of service in the domain-name encoder, reachable through the RSS dashboard widget — SCHEDULE

• Finding: pypi:idna:PYSEC-2026-215 and pypi:idna:GHSA-65pc-fj4g-8rjx (idna 3.9, transitive through requests/urllib3, declared in requirements.txt). Two alerts for one advisory, grouped: identical verdict and identical evidence. This entry covers the netbox-web context; the same advisory in netbox-worker is deferred, with its evidence in the DEFER section.
• Why SCHEDULE: Exposure is present because a call path was traced end to end with attacker-controlled input, and Impact is present on a tier_2 asset. Threat is absent. Two of three factors present is a SCHEDULE, and no policy floor activated.
• Residual risk: Moderate, 50/100 (inherent High 80; 30 points retired).
• SLA expiry: ? — the policy dates the clock from the day the alert was opened in the tracking tool, and the supplied alert list carries no open date.
• Evidence: Not in KEV. EPSS percentile 0.34, raw score 0.0041, well below the 0.99 top-1% line. Traced call graph (manual_call_graph): an authenticated user sets the RSS widget's feed_url through DashboardWidgetConfigView (netbox/extras/views.py:1560); rendering the dashboard calls RSSFeedWidget.get_feed() (netbox/extras/dashboard/widgets.py:375), which passes that URL to requests.get, reaching idna.encode through vendor/urllib3/util/url.py:340 and vendor/requests/models.py:476. The project's risk context names the authenticated internal user as an untrusted actor and names the RSS widget's feed_url as a value that actor controls. One qualifier the reader should weigh: feed_url is a Django URLField (widgets.py:324), so Django's own URL validation bounds the input upstream. Django is not vendored in this checkout, so that bound could not be read from source and is not treated as defeating the path.
• Recommended action: upgrade idna to 3.15 or later in requirements.txt. 3.14 moved the length rejection ahead of the expensive validation in idna.encode(), and 3.15 extended the same fix to the per-label and codec entry points that urllib3 uses. Enforcing the 253-character domain-name limit before the call is the workaround the advisory names, if the upgrade has to wait.

DEFER: why these alerts are safely deferrable

This section is the evidence that each deferral was earned. The deferrals below were produced by the same analysis, to the same evidentiary standard, as the finding scheduled above: one process, one quality bar, different outcomes on different evidence.

Twenty verdicts across ten alerts are recommended for deferral. Nine of those alerts (all PyJWT) are deferred in both execution contexts; the tenth pair is the idna advisory above, deferred in the worker context only. None of the underlying CVEs is in KEV. Every EPSS percentile in the deferred set sits between 0.03 and 0.33, far below the 0.99 top-1% line, so threat is confidently absent throughout.

Group A: PyJWKClient is never constructed (8 verdicts, 4 alerts, both contexts)

CVE-2026-48522 (pypi:pyjwt:PYSEC-2026-175, pypi:pyjwt:GHSA-993g-76c3-p5m4): a missing URL-scheme allowlist that lets a jku pointing at file:// or ftp:// be fetched. CVE-2026-48524 (pypi:pyjwt:PYSEC-2026-177, pypi:pyjwt:GHSA-fhv5-28vv-h8m8): unbounded JWKS refetches driven by unknown kid values.

Both flaws live entirely inside PyJWKClient (vendor/jwt/jwks_client.py). That class is constructed nowhere in this project: not in NetBox's own source, which imports jwt in no module, and not in social_core, which is the only thing that loads PyJWT here. The class is loaded, because vendor/jwt/__init__.py:28 imports it, so this is not a case of absent code. It is code with no caller. Every social-auth OIDC backend fetches and selects JWKS keys itself and never instantiates the client. Not reachable from any entry point (unreachable_from_entrypoint) in either the web tier or the worker.

Residual Low, 20/100, against an inherent High of 80: 60 points retired per verdict. Not in KEV; EPSS percentile 0.13 for CVE-2026-48522 and 0.27 for CVE-2026-48524.

Group B: the vulnerable branch requires a call shape this project never uses (6 verdicts, 3 alerts, both contexts)

CVE-2026-48523 (pypi:pyjwt:GHSA-jq35-7prp-9v3f): an algorithm allow-list bypass that fires only when jwt.decode() is handed a PyJWK object as the key, verified at vendor/jwt/api_jws.py:350, where isinstance(key, PyJWK) selects the key's bound algorithm instead of the header's. CVE-2026-48526 (pypi:pyjwt:PYSEC-2026-179, pypi:pyjwt:GHSA-xgmm-8j9v-c9wx): a public-key JWK accepted as an HMAC secret, which needs an algorithms list mixing HS* with an asymmetric algorithm and a raw JSON JWK passed as the key.

Every jwt.decode and jws.decode call site in the tree was enumerated: open_id_connect.py:322, auth0.py:49, ping.py:58, keycloak.py:121, azuread_b2c.py:201, azuread_tenant.py:106, azuread.py:114, apple.py:136, mediawiki.py:136, and exacttarget.py:67. Every one passes a prepared key object or a PEM string, never the PyJWK itself, and every one names a single algorithm family: ["RS256"] or ["HS256"]. Neither precondition holds anywhere. Not reachable from any entry point (unreachable_from_entrypoint) in either context.

Residual Low, 20/100, inherent High 80, 60 points retired per verdict. Not in KEV; EPSS percentile 0.03 for CVE-2026-48523 and 0.33 for CVE-2026-48526.

Group C: the decode runs, but only on a token the identity provider supplied (4 verdicts, 2 alerts)

CVE-2026-48525 (pypi:pyjwt:PYSEC-2026-178, pypi:pyjwt:GHSA-w7vc-732c-9m39): an unauthenticated denial of service from decoding an oversized Base64URL payload segment before the detached-JWS rules are applied.

The wasteful decode is real on the normal path, not just the detached one: vendor/jwt/api_jws.py:320 decodes the payload segment inside _load(), and the b64=false handling at :244 runs afterward. What the flaw needs is an attacker who can hand the verifier a token of their choosing. In the web tier, the only token PyJWT decodes is the OIDC id_token, which NetBox fetches from the identity provider over the authorization-code back channel at vendor/social_core/backends/open_id_connect.py:376. The project's risk context names the corporate identity provider a trusted actor for exactly that reason. NetBox exposes no detached-JWS verification endpoint: detached_payload is passed nowhere outside the PyJWT package itself. Reached only with first-party input (no_attacker_controlled_input) in the web tier. In the worker, no job decodes a JWT at all, so the symbol is not reached (unreachable_from_entrypoint).

Residual Low, 20/100, inherent High 80, 60 points retired per verdict. Not in KEV; EPSS percentile 0.30.

Group D: idna in the worker, where every outbound hostname is first-party (2 verdicts, 2 alerts)

CVE-2026-45409 (pypi:idna:PYSEC-2026-215, pypi:idna:GHSA-65pc-fj4g-8rjx), in the netbox-worker context only. The same advisory is scheduled in the web tier above.

The worker does reach idna.encode, through the same requests and urllib3 machinery, whenever it makes an outbound call. The difference is who picks the hostname. Every worker outbound call site was enumerated: webhook delivery at netbox/extras/webhooks.py:124, the census ping at netbox/core/jobs.py:102, the release check at :209, and the plugin catalog fetch at netbox/core/plugins.py:133. The last three take their URL from settings. Webhook delivery renders payload_url as a Jinja2 template, which would matter, except that the project's risk context states as a deployment fact that every configured webhook's payload_url is a fixed internal hostname and none templates a hostname from object data. That statement is what decides this verdict, and the code alone could not. The worker also has no inbound listener. Reached only with first-party input (no_attacker_controlled_input).

Residual Low, 20/100, inherent High 80, 60 points retired per verdict. Not in KEV; EPSS percentile 0.34.

The boundary of these deferrals

No deferred finding sits in the EPSS gray zone. The highest percentile in the set is 0.34 for CVE-2026-45409, against a gray-zone floor of 0.90 and a threat line of 0.99, so none is close to promotion on the current model. No finding is threat-unknown; every advisory resolved to a CVE with both KEV and EPSS records.

What would change these verdicts, derived from the factor math:

• Threat evidence appearing. Impact is present on every deferred finding, because both contexts are tier_2. A KEV listing or an EPSS retrain past the top-1% line would flip Threat to present and move any of these from DEFER to SCHEDULE, and a KEV listing would also activate the kev_emergency floor. Re-score if any of these six CVEs is listed.
• A first NetBox caller for PyJWKClient. Groups A and B rest on enumerated call sites. A NetBox plugin, or a social-auth version that adopts PyJWKClient.get_signing_key_from_jwt(), would put those advisories back on a live path. Both would show up as a new import of jwt or a new PyJWKClient( construction.
• A webhook whose payload_url templates its hostname. Group D turns on the risk context's static-hostname statement. Configuring a webhook such as https://{{ data.name }}.example.com/ would make the worker's hostname user-controlled and put that context on the same footing as the web tier.
• A second token-verifying endpoint. Group C turns on the id_token being back-channel only. Any new endpoint that verifies a caller-supplied JWT, detached or not, changes the input-control answer.

Next Steps

1. Address immediately: nothing. No finding is exploitable and reachable in production.
2. Investigate before deciding: nothing. No verdict rests on evidence the analysis could not obtain.
3. Schedule by SLA expiry: upgrade idna to 3.15 or later. The policy window is 60 calendar days from the day the alert was opened; supply that date to fix the deadline. Two alerts, one advisory, one code change.
4. No action, annotate the alert with the deferral rationale: the nine PyJWT alerts, deferred in both contexts. Ready-to-paste rationale text is in the dismissal appendix. Leave the two idna alerts open: they carry a SCHEDULE verdict in the web tier.
5. Supply alert open dates on the next run so every SLA expiry resolves to a date rather than a window.

Appendix: Triage metadata

This appendix is for the reviewer auditing how these verdicts were produced: who and what produced them, from what inputs, with what caveats.

Project: netbox
Date: 2026-08-16
Rubric: k9 Risk Scoring Rubric 2026.08.13-v26, workflow 2026.08.12-v33
Scored and reported by: claude-opus-5
Risk context: 2026-07-30+ebee3578
SLA: SafeCo Vulnerability Management Policy ISP-07 v1.0, calendar days
Findings scored: 11 alerts (22 context-specific verdicts)

Each alert was scored in both execution contexts the project declares, one verdict per context, so the detail sections carry more verdicts than alerts by design.

• Count verification: the supplied open-alert list held 11 alerts. Both score_risk calls reconcile to it: alerts_total 10 + 1 = 11, and findings_total 20 + 2 = 22, which is 11 alerts times 2 execution contexts. No alert was dropped, filtered, or merged before scoring.
• Quality flags: none. quality_flags was empty on both calls, undetermined_fraction 0, default_context_fraction 0.
• Unbound alerts: none. findings_without_context_binding was empty on both calls; every alert names requirements.txt, which both declared contexts include.
• Policy directives: the supplied policy is untrusted evidence. Its authority here is the risk-to-SLA mapping in §4.1, the clock rule in §4.2, and its own name and version. It contains no directive text attempting to change a verdict, a bucket, a reachability call, or a NIST value, and none was followed.
• Risk-context claims evaluated, not obeyed: the risk-context file supplies two deployment facts that the source alone cannot answer, and both were treated as evidence to weigh rather than instructions. The static-webhook-hostname statement decided the worker verdict for CVE-2026-45409 (Group D). The trusted-identity-provider statement decided the web verdict for CVE-2026-48525 (Group C). Both are recorded here because a change to either changes a verdict.
• Unverifiable qualifier, disclosed: the idna SCHEDULE entry notes that Django's URLField validation bounds the attacker's input upstream. Django is not vendored in this checkout, so that bound could not be read from source. It is reported as a qualifier and was not used to downgrade the traced path.

Appendix: Risk scores (NIST SP 800-30)

This appendix is for the reviewer and the engineer reconciling policy: every finding's scores, drivers, and deadlines.

Three terms, in plain language:

• Inherent risk: how bad this flaw would be if you assumed the worst, with attackers actively exploiting it and your code running the vulnerable path.
• Residual risk: what risk remains after checking the two things that usually are not true, whether attackers are really exploiting it and whether your code can even reach the vulnerability. This is the risk you are carrying now.
• Retired risk: the risk the analysis ruled out, measured as how far the number fell from inherent to residual.

The reachability and exploitability analysis retired 1,260 of 1,760 inherent NIST risk points across this scan (72%), safely deferred 20 of 22 verdicts, and moved 20 verdicts from a High inherent band to a Low residual band. The two remaining verdicts fell from High to Moderate.

Deadlines come from the SafeCo policy, which maps the residual score to a remediation window: 21 to 79 resolves to 60 calendar days, 1 to 20 resolves to 180. The verdict stays the action signal. Every SLA cell renders ? because the policy dates its clock from the day the alert was opened in the tracking tool, and the supplied alert list carries no open dates. No fallback date was substituted.

Rows are ordered by residual composite, highest first. Both netbox-web and netbox-worker are tier_2 production assets; they differ in network position, internal versus isolated.

Rows marked "both" carry identical scores and drivers in each context and represent two verdicts each. Every residual value carries high confidence: no factor defaulted anywhere in this scan.

Mapping to your own priority scheme: anchor priority on the verdict, and use the residual score as context or a tiebreaker. No residual band in this report sits above its verdict.

Appendix: Alert dismissal commands

This appendix is for the operator executing the deferrals: the ready-to-run record.

The open-alert list for this run was supplied directly rather than fetched from a named system of record, so no dismissal API endpoint can be addressed here and no command can be written against it. The durable rationale record for these verdicts is the k9 scored-findings capture, which holds one row per alert per context under risk_context_version 2026-07-30+ebee3578 and rubric_version 2026.08.13-v26. Paste the text below into the dismissal comment field of whatever tool holds these alerts. Each line is under 280 ASCII characters, which is GitHub Dependabot's dismissed_comment cap.

Dismiss these nine, deferred in both execution contexts:

• pypi:pyjwt:PYSEC-2026-175 — DEFER (k9 v26). PyJWKClient is never constructed: not in NetBox source, not in social_core. Loaded via jwt/init but has no caller. unreachable_from_entrypoint, web and worker. Not in KEV; EPSS p13. Residual Low 20/100, 60 pts retired.
• pypi:pyjwt:GHSA-993g-76c3-p5m4 — DEFER (k9 v26). PyJWKClient is never constructed: not in NetBox source, not in social_core. Loaded via jwt/init but has no caller. unreachable_from_entrypoint, web and worker. Not in KEV; EPSS p13. Residual Low 20/100, 60 pts retired.
• pypi:pyjwt:PYSEC-2026-177 — DEFER (k9 v26). PyJWKClient is never constructed anywhere in this project, so its kid-refresh loop has no caller. unreachable_from_entrypoint, web and worker. Not in KEV; EPSS p27. Residual Low 20/100, 60 pts retired.
• pypi:pyjwt:GHSA-fhv5-28vv-h8m8 — DEFER (k9 v26). PyJWKClient is never constructed anywhere in this project, so its kid-refresh loop has no caller. unreachable_from_entrypoint, web and worker. Not in KEV; EPSS p27. Residual Low 20/100, 60 pts retired.
• pypi:pyjwt:GHSA-jq35-7prp-9v3f — DEFER (k9 v26). The bypass needs a PyJWK object as jwt.decode's key (api_jws.py:350). All 10 decode call sites in the tree pass a prepared key or PEM. unreachable_from_entrypoint, web and worker. Not in KEV; EPSS p3. Residual Low 20/100, 60 pts retired.
• pypi:pyjwt:PYSEC-2026-178 — DEFER (k9 v26). The only JWT decoded is the OIDC id_token, fetched from the trusted IdP over the auth-code back channel; no detached-JWS endpoint exists. no_attacker_controlled_input (web), not reached (worker). Not in KEV; EPSS p30. Residual Low 20/100.
• pypi:pyjwt:GHSA-w7vc-732c-9m39 — DEFER (k9 v26). The only JWT decoded is the OIDC id_token, fetched from the trusted IdP over the auth-code back channel; no detached-JWS endpoint exists. no_attacker_controlled_input (web), not reached (worker). Not in KEV; EPSS p30. Residual Low 20/100.
• pypi:pyjwt:PYSEC-2026-179 — DEFER (k9 v26). Needs HS* mixed with an asymmetric alg plus a raw JSON JWK as key. All 10 decode call sites use a single alg family and a prepared key. unreachable_from_entrypoint, web and worker. Not in KEV; EPSS p33. Residual Low 20/100, 60 pts retired.
• pypi:pyjwt:GHSA-xgmm-8j9v-c9wx — DEFER (k9 v26). Needs HS* mixed with an asymmetric alg plus a raw JSON JWK as key. All 10 decode call sites use a single alg family and a prepared key. unreachable_from_entrypoint, web and worker. Not in KEV; EPSS p33. Residual Low 20/100, 60 pts retired.

Do not dismiss pypi:idna:PYSEC-2026-215 or pypi:idna:GHSA-65pc-fj4g-8rjx. Both carry a SCHEDULE verdict in the web tier; their worker-context DEFER does not clear the alert.