Authenticated SonarQube CLI exits 51 without a visible finding inventory after server upgrade

SonarQube Server / Community Build
1

Authenticated SonarQube CLI exits 51 without a visible finding inventory after server upgrade

Please provide a supported way to obtain complete masked native results and authentication/transport
status through the existing CLI-authorized credential context. The failure below persists after a
supported, healthy server upgrade. We are not requesting a finding waiver or a repeated blind scan.

Versions and accepted server state

  • SonarQube CLI distribution: 1.11.0.16877; CLI version output: 1.11.0.
  • Installed native secrets detector: 2.53.1.13823; CLI system status reports no update available.
  • macOS 27.2, build 26B123, arm64.
  • Before upgrade: Community Build 26.6.0.123539.
  • Accepted upgraded server: Community Build 26.10.0.133078, chart 2026.5.1003.
  • Upgraded image digest: f95aaa9016dd4e92c7d70691167a6d96dbb5d8acffd61eba1cb4335d364a7840.
  • Live status immediately before the retest: UP. CLI system status: authenticated, token active.
    No credential value was read or exported by the diagnostic launcher.
  • Deployment owner accepted migration, retained projects/history/gates/profile bindings, empty
    compute-engine queues, and readable Web/CE truststores without either advisory root. This server
    mitigation is not represented as proof about native-client TLS or provisioned scanner JREs.
  • Server acceptance artifact SHA-256, independently supplied and locally verified:
    145b5b586efd0ac163d2b6ef255537ecb51d8ef4831274b45e0befe068f752c1.

One authorized post-upgrade retest

Completed at 2026-10-30T19:32:17Z. We scanned only a retained, separately authored, never-issued
synthetic control, not application source. It is a 96-byte Python file with an ordinary basename
reporting_control.py. Its mapping key is password; the value was an explicit
UNISSUED-DIAGNOSTIC- prefix followed by 24 random bytes encoded as hex. It was never issued by
or used with any service.

Control SHA-256 before and after:
e61f0c545fe6ffdb5c31e901bdaeeb1ca8e488134b216ee24f9c2aaad0a0389e.
The retained file was used in place, without copying, renaming, or changing its basename.

The exact argv shape was sonar analyze secrets <absolute-retained-path>/reporting_control.py.
Only the private path prefix is omitted from this public draft; the complete actual argv is retained
privately. Existing managed CLI auth was used, with a fresh private SONAR_SECRETS_CACHE_DIR, as in
the pre-upgrade control condition. No timeout, credential, filter, allowlist, or model setting changed.
No direct keychain lookup, alternate broker, tokenless fallback, or native bypass was used.

  • Exit status: 51.
  • stdout: 0 bytes; SHA-256
    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
  • stderr: 85 bytes; SHA-256
    eb2e05eccd6ada45e41e004ca3591a49f13f7d1b43cfe29753942007f490321d.
  • Complete stderr text:
❌ Secrets found · 618ms
  → Remove the reported secret(s), then rerun the scan.

There is no rule key, confidence, source span, or masked finding inventory. This is complete visible
managed-CLI output, not a claim that raw native JSON was captured. CLI authentication being active
is not proof of successful native authentication or complete native result visibility.

The pre-upgrade control also exited 51 with generic output. The allowed post-upgrade attempt has
been consumed; we will not repeat the unchanged failure without a supported new diagnostic condition.
Original application inputs remain unread/unscanned by this investigation.

Supported-interface constraint

Installed wrapper help exposes paths, --stdin, and help. It documents neither native verbose
forwarding nor a same-principal credential relay. Native help documents --verbose, --json,
and token/URL environment authentication. A hidden token prompt or a new helper access grant does
not establish authority to export the CLI-held credential through another principal.

Earlier noninteractive read-only legacy OS-keychain and published Bun broker probes both stopped
before obtaining a credential or launching the native detector. They were not repeated. They do
not establish that the existing CLI credential is invalid or explain the native reporting problem.
No access controls, authentication, global OS trust, or scanner trust configuration was changed.

Exact requested response

  1. Give the exact supported invocation or official diagnostic route for CLI 1.11.0.16877 and native
    2.53.1.13823 that retains the existing CLI-authorized credential context while exposing complete
    masked native issue/error/configuration output and authentication/transport/result-visibility status.
    If a supported patch/build is required, identify it precisely for review; no update is authorized
    merely by this request.
  2. Specify whether verbose output can include tokens or authorization headers and how the supported
    route guarantees redaction before persistence. The JSON masked-secret promise alone does not
    establish verbose authentication-log safety.
  3. Explain the supported meaning of exit 51 with no visible finding inventory. Identify whether the
    inventory is intentionally limited, unavailable because of native authentication/transport, or lost
    at a presentation boundary; do not assume a JSON parser defect from this symptom alone.
  4. Confirm native confidence/filter/exit semantics, including the documented LOW-confidence behavior
    of --disable-test-file-detection for 2.45.0.11557 and 2.53.1.13823. The pinned older binary is a
    separate consumer, not the detector used for this authenticated CLI retest.

No licensing, permission, parser, filter, cache, or TLS cause has been established. We cannot accept
an allowlist, renamed input, tokenless fallback, reduced coverage, extra keychain permissions,
credential replacement, or finding acceptance as a substitute for complete classification.

Artifacts available for review

Sanitized version/status facts, the output text/hashes above, synthetic construction/hash/size,
wrapper/native help declarations, and no-launch broker metadata are available. Private actual argv,
raw visible-output files, exact server acceptance proof, and historical receipts are retained locally.
Do not request token values, environment dumps, keychain contents, auth caches, original application
source, or unreviewed verbose logs.

References

2

Hi @osamakaram, we really appreciate it when posts are written in a natural and concise way, and not in the form of a verbose AI-generated dump.

Let me see if I can summarize what you’re reporting:

  • You are finding a false positive in SonarQube CLI’s secret detection.
  • SonarQube CLI doesn’t tell you enough information about the detected secret so you cannot tell why was a secret detected.
  • SonarQube CLI doesn’t print or export diagnostics about its run, not only concerning secret detection itself but also concerning authentication or transport details.

May I suggest we start by having a look at that false positive? Could you share a reproducer? With that in hand, we can see if/why the secret is being detected, and consider which information would be relevant for us to expose so that users like you can better understand the results of the secrets analysis.

4

Thanks, Andrés. I confirmed that the example below reproduces the reporting issue on CLI 1.12.0. It exits 51 with empty stdout, and stderr says “Secrets found” without identifying the rule or location. The input is a generated dummy value. Is there a supported way to see the rule and location with the value masked, using the existing CLI login?

# Run in a scratch directory with the CLI already authenticated.
printf 'config = {"password": "UNISSUED-DIAGNOSTIC-%s"}\n' \
  "$(openssl rand -hex 24)" > reporting_control.py
SONAR_SECRETS_CACHE_DIR="$(mktemp -d)" \
  sonar analyze secrets "$PWD/reporting_control.py"