Summary

routes::secrets_env::upsert_secret validated the secret value for \n / \r / \0 (lines 24-33) but the key check (line 44) only rejected =, leading/trailing whitespace, and empty.

A key containing an interior newline (e.g. FOO\nBAR) passes every check — key.trim() != key is false because the newline is not at an edge, and key.contains('=') is false — so the out.push_str(&format!("{key}={value}\n")) write emits:

FOO
BAR=value

injecting an extra BAR=value line into secrets.env. That file is loaded into the process environment at daemon boot (librefang_extensions::dotenv::load_dotenv) and inherited by sidecar child processes, so the injected line becomes a live environment variable.

This is a direct inconsistency with the sibling helper routes::skills::write_secret_env, which already rejects key.contains('\n') || key.contains('\r').

Fix

Reject \n / \r / \0 in the key before the existing checks, mirroring the hardened write_secret_env path, so a key can never break the KEY=VALUE line framing.

Tests

Adds an in-crate #[cfg(test)] module:

• key_with_newline_is_rejected_and_does_not_inject_a_line
• key_with_carriage_return_or_nul_is_rejected
• well_formed_key_still_writes_a_single_line (positive case)

Verification

This host has no native Rust toolchain and no working container runtime, so local cargo verification was not possible — CI is the gate. The change is a few lines of input validation plus self-contained unit tests. Reviewers / CI: cargo test -p librefang-api.

Scope

One of several independent findings from a repo audit; filed as its own PR per the one-PR-one-domain policy.