Summary
handle_incoming_invite dumps all SIP headers of every inbound INVITE to stderr with eprintln!, unconditionally (not gated by any tracing/log level). That includes the Authorization header (digest username/realm/nonce/response — credential material) and From/To/Contact/P-Asserted-Identity (caller PII / routing).
Location
crates/asterisk-sip/src/event_handler.rs
event_handler.rs:351-355:
eprintln!("[DEBUG] handle_incoming_invite: call_id={}, exten={}, caller={}", …);
eprintln!("[DEBUG] All headers:");
for h in &request.headers {
eprintln!("[DEBUG] {}: {}", h.name, h.value); // prints Authorization, From, Contact, …
}- Plus auth-outcome prints at
event_handler.rs:405 and :424, and ~a dozen more eprintln!("[DEBUG] …") through the file (BYE/hold/re-INVITE at 367, 913, 1681, 1689, 1698, 1733, …), and in notify_service.rs:158-212.
Impact
Credential-adjacent material and PII written to stderr/pod logs on the normal call path, at any verbosity, for anyone with log access. Low severity (digest response is not the plaintext password) but it violates the secret-handling discipline the M3 PIN work established, and log volume is a minor DoS in itself.
Recommended fix
Replace the eprintln! calls with tracing::debug!/trace! (so they honor the log filter), and for the header dump either drop it or redact Authorization/Proxy-Authorization/P-*-Identity values. The single eprintln! inside authenticator.rs::verify (auth-header presence) is already removed in PR #125; this issue covers the broader event_handler.rs/notify_service.rs sweep, which is outside that PR's auth-module scope.
Summary
handle_incoming_invitedumps all SIP headers of every inbound INVITE to stderr witheprintln!, unconditionally (not gated by any tracing/log level). That includes theAuthorizationheader (digest username/realm/nonce/response — credential material) andFrom/To/Contact/P-Asserted-Identity(caller PII / routing).Location
crates/asterisk-sip/src/event_handler.rsevent_handler.rs:351-355:event_handler.rs:405and:424, and ~a dozen moreeprintln!("[DEBUG] …")through the file (BYE/hold/re-INVITE at 367, 913, 1681, 1689, 1698, 1733, …), and innotify_service.rs:158-212.Impact
Credential-adjacent material and PII written to stderr/pod logs on the normal call path, at any verbosity, for anyone with log access. Low severity (digest response is not the plaintext password) but it violates the secret-handling discipline the M3 PIN work established, and log volume is a minor DoS in itself.
Recommended fix
Replace the
eprintln!calls withtracing::debug!/trace!(so they honor the log filter), and for the header dump either drop it or redactAuthorization/Proxy-Authorization/P-*-Identityvalues. The singleeprintln!insideauthenticator.rs::verify(auth-header presence) is already removed in PR #125; this issue covers the broaderevent_handler.rs/notify_service.rssweep, which is outside that PR's auth-module scope.