Credential disclosure in netbox-community NetBox REST and GraphQL APIs

NetBox through 4.7.0 fails to redact sensitive data source backend credentials in REST and GraphQL API responses. Authenticated users with only view permission can retrieve plaintext passwords and secret keys for Git and Amazon S3 backends through API endpoints, gaining unauthorized access to external repositories and storage buckets.

• Product: netbox-community NetBox.
• Affected scope: the structured record identifies semver versions from 0 through 4.7.0, inclusive, as affected.
• Relevant backends: Data Sources using Git with the password key and Amazon S3 with the aws_secret_access_key key.
• Deployment condition: the instance must contain a Data Source with these credentials and grant core.view_datasource to an account able to call the API.
• The record sets the default status outside the listed range to unaffected, but the available evidence does not confirm that every later or parallel release branch is safe.

netbox-community NetBox stores Data Source connection settings in the JSON parameters field. The Git backend marks password as sensitive and the Amazon S3 backend marks aws_secret_access_key as sensitive, but the API serialization paths do not apply that masking. The REST DataSourceSerializer includes parameters in its serialized field list, while the GraphQL DataSourceType exposes all model fields with fields='__all__', including parameters. Object-permission filtering still limits the Data Sources returned to users with core.view_datasource, but once a user can view the object, the secret can be returned in plaintext; change permission, staff status, and superuser status are not required. The attack requires an authenticated account with Data Source view permission and access to the REST or GraphQL API. The available evidence does not establish how a fix handles other backends beyond Git and Amazon S3.

The issue is reachable over the network through NetBox REST and GraphQL APIs. An attacker needs an authenticated account with Data Source view permission, but does not need write permission, staff status, or superuser status. The record describes low-privilege access, low complexity, and no interaction from another user. The record also marks a public exploit reference as available; however, the supplied evidence does not confirm active exploitation, a named campaign, a specific victim, or a specific intrusion indicator.

The flaw discloses plaintext credentials from NetBox to authenticated users who can view Data Sources. The direct technical outcome is loss of credential confidentiality; impact to NetBox integrity or availability is not confirmed. If the credentials remain valid, their holder may access a Git repository or Amazon S3 bucket within the permissions granted by the external system. The practical severity depends on each credential's permissions, the number of Data Sources exposed, and whether the credential is reused elsewhere.

• A Git password or token may be retrieved by a NetBox user who only has read access; the actual repository permissions depend on the exposed credential.
• An Amazon S3 aws_secret_access_key may permit bucket access or other actions allowed by the associated AWS identity, but the exact external permissions are not established.
• Exposed credentials can create unauthorized access to external systems and may require credential rotation, incident investigation, access-log review, and disruption to synchronization jobs.
• The available evidence confirms credential disclosure, but does not confirm data modification, service interruption, or a specific breach.

1. Apply the vendor patch or a release that contains the fix. The record says a patch is available, but it does not provide an exact fixed release; do not infer that every version after 4.7.0 is safe.
2. Until a suitable fix is verified, restrict core.view_datasource to accounts that genuinely require it and limit API access for ordinary read-only users or integrations that do not need connection parameters.
3. Rotate all Git passwords or tokens and S3 secret access keys stored in Data Sources that may have been returned through the API. Update the credentials in the external systems and review access logs after rotation.
4. After upgrading, test both REST and GraphQL independently to confirm that sensitive keys are no longer returned in plaintext. Do not treat masking in the web UI as proof that the API paths are fixed.
5. Reconcile the vendor's release branches and fix notices before closing the issue, because the available evidence does not establish fixed boundaries for each branch.

• Inventory deployed NetBox versions and Data Sources that use Git or Amazon S3 backends.
• Review users and API tokens granted core.view_datasource, especially read-only service accounts and integrations.
• Check reverse-proxy, API-gateway, and application logs for requests to /api/core/data-sources/ and GraphQL queries requesting data_source_list with parameters. This is precautionary review, not a confirmed IOC.
• In a test environment, use an account with only view permission to verify whether REST and GraphQL responses redact sensitive keys; do not record or copy returned secret values.
• If plaintext was returned, treat the related Git passwords or tokens and S3 secret access keys as potentially exposed, then review access history on the external services and rotate the credentials.