Custom link template injection exposes NetBox user credentials

NetBox versions 2.9.5 before 4.7.0 contain a server-side template injection vulnerability that allows a low-privileged user with the "Can add custom links" permission to steal session cookies and API tokens of other users by exposing the raw Django HttpRequest object to the Jinja2 template context. Attackers can craft a custom link template embedding request.COOKIES['sessionid'] or a user's API token into an img src URL, which bypasses the clean_html sanitizer and auto-exfiltrates the victim's credentials to an attacker-controlled host when a privileged user views the object, enabling full account takeover.

• Affected: NetBox from netbox-community, product netbox, from 2.9.5 through releases before 4.7.0.
• Fixed boundary: NetBox 4.7.0 includes the change that restricts the request object passed to custom link templates and removes access to cookies, headers, and session state.
• The normalized record marks the default status as unaffected outside the explicit affected range. No separate backport or parallel branch is confirmed by the available evidence.

NetBox renders custom links with Jinja2 and previously exposed the raw Django HttpRequest object in the template context. That object could provide sensitive request data, including session cookies and information used to obtain or expose API tokens. A user with the "Can add custom links" permission can create a custom link template that references request.COOKIES['sessionid'] or a user's API token and places the value in an img src URL. When a privileged user views an object containing the link, the browser can issue a request to an attacker-controlled host and disclose the value embedded in the URL. The described path bypasses the clean_html sanitizer. The fix changes the custom link and webhook contexts to use a safe request context that exposes only a restricted set of attributes, including id, path, path_info, method, GET, and user; cookies, headers, and session state are no longer available.

The vulnerability is reachable through the NetBox web interface and requires an authenticated low-privileged user who also has the "Can add custom links" permission. The attack does not require complex conditions, but it requires passive interaction from a privileged user who views an object containing the crafted custom link. The stolen data is sent to an attacker-controlled host through a browser-generated request. No direct unauthenticated path is described in the available evidence. The supplied record does not confirm a public exploit or known exploitation; that is a reporting limitation, not evidence that abuse has not occurred.

• The direct technical outcome is disclosure of user credentials through a browser-generated request.
• A stolen session cookie may let the attacker act as the affected user, while an API token may provide API access within the token's permission scope.
• The available description supports possible full account takeover, but it does not establish arbitrary code execution or service disruption.
• The practical scope depends on whether a privileged user views an object containing the custom link and on the privileges associated with the exposed session or API token.

• The attacker may collect session cookies or API tokens belonging to other users, including users with elevated privileges who view affected objects.
• A stolen session cookie may allow user impersonation and full account takeover.
• A disclosed API token may enable NetBox API access according to the token's permissions.
• Response may require session invalidation, API token rotation, review of custom links, and examination of privileged accounts. The available evidence does not establish a specific breach or compromise.

1. Upgrade NetBox to 4.7.0, the release identified by the project evidence as restricting the request context supplied to custom link templates.
2. Before upgrading, remove the "Can add custom links" permission from accounts that do not require it, especially low-privileged accounts. Review and remove custom link templates that reference request data or load resources from external hosts. These are compensating measures, not a confirmed vendor fix.
3. If a vulnerable instance may have rendered suspicious links for privileged users, invalidate potentially affected sessions, rotate API tokens, and review account activity as a precaution.
4. If using another branch or a backport, verify with the release source that the branch includes the request-context restriction. Do not infer that another branch is fixed solely because 4.7.0 contains the change.

1. Inventory deployed NetBox versions and identify systems within the affected range.
2. Review assignments of the "Can add custom links" permission, especially for low-privileged accounts.
3. Inspect existing custom link templates for references to request, request.COOKIES['sessionid'], API tokens, img elements, or external resource URLs.
4. Where suitable telemetry exists, review browser, proxy, DNS, and egress data for unexpected requests to external hosts occurring when privileged users view objects. Treat this as a precautionary monitoring signal, not a confirmed indicator of compromise.
5. If suspicious templates or possible exposure to privileged users are found, invalidate relevant sessions, rotate API tokens, and investigate account activity. The available evidence does not define a unique log event or IOC.