Skip to content

fix: redact longer overlapping secrets first#4624

Closed
NikkeTryHard wants to merge 1 commit intobrowser-use:mainfrom
NikkeTryHard:fix-sensitive-data-overlap
Closed

fix: redact longer overlapping secrets first#4624
NikkeTryHard wants to merge 1 commit intobrowser-use:mainfrom
NikkeTryHard:fix-sensitive-data-overlap

Conversation

@NikkeTryHard
Copy link
Copy Markdown

@NikkeTryHard NikkeTryHard commented Apr 6, 2026

Fixes #4609.

Summary

Fixes a partial secret leak in both AgentHistory._filter_sensitive_data_from_string and MessageManager._filter_sensitive_data when one sensitive value is a substring of another.

Previously, secrets were replaced in dict iteration order. If abc was replaced before abc123, the longer value could become partially redacted as short_token123, leaving the suffix visible.

This change sorts sensitive values by descending length before replacement so longer matches are always redacted first in both redaction paths.

The PR is intentionally kept to one atomic commit: the implementation changes and their direct regression coverage stay together for easier review and safe revert.

Tests

  • Added regression coverage for overlapping secrets in the AgentHistory redaction path
  • Extended MessageManager sensitive-data coverage to include overlapping secrets
  • uv run pytest tests/ci/security/test_sensitive_data.py
  • uv run pre-commit run --files browser_use/agent/views.py browser_use/agent/message_manager/service.py tests/ci/security/test_sensitive_data.py

@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Apr 6, 2026

CLA assistant check
All committers have signed the CLA.

Copy link
Copy Markdown
Contributor

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 2 files

@NikkeTryHard NikkeTryHard force-pushed the fix-sensitive-data-overlap branch from 475baa3 to d76c94d Compare April 6, 2026 21:37
@laithrw
Copy link
Copy Markdown
Member

laithrw commented Apr 11, 2026

Thanks for the PR and for looking into this! It looks great, but I'm closing this in favor of #4660, which centralizes the redaction logic into a shared helper to keep the code a bit cleaner.

@laithrw laithrw closed this Apr 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: sensitive_data redaction breaks when one secret is substring of another (partial leak)

3 participants