# Authenticated SonarQube CLI exits 51 without a visible finding inventory after server upgrade **URL:** \ **Category:** SonarQube Server / Community Build\ **Tags:** sonarqube-cli\ **Created:** [October 30, 2026, 9:35pm UTC](https://community.sonarsource.com/t/authenticated-sonarqube-cli-exits-51-without-a-visible-finding-inventory-after-server-upgrade/190757 "2026-10-30T21:35:49Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![osamakaram](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/osamakaram/32/78091_2.png) [@osamakaram](https://community.sonarsource.com/u/osamakaram)\ **Post date:** [October 30, 2026, 9:35pm UTC](https://community.sonarsource.com/t/authenticated-sonarqube-cli-exits-51-without-a-visible-finding-inventory-after-server-upgrade/190757/1 "2026-10-30T21:35:49Z")
# 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 /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: ```plaintext ❌ 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 - [Official secrets detection documentation](https://docs.sonarsource.com/sonarqube-cli/analysis/secrets-detection) - [Official eMudhra advisory](https://docs.sonarsource.com/sonarqube-community-build/server-update-and-maintenance/release-notes/emudhra-certificate-authority-compromise) - [Published CLI keychain broker](https://github.com/SonarSource/sonarqube-cli/blob/1.11.0.16877/src/core/host/keychain.ts) ---
**Author:** ![andres](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/andres/32/76342_2.png) [@andres](https://community.sonarsource.com/u/andres)\ **Post date:** [November 3, 2026, 10:20am UTC](https://community.sonarsource.com/t/authenticated-sonarqube-cli-exits-51-without-a-visible-finding-inventory-after-server-upgrade/190757/2 "2026-11-03T10:20:51Z")
Hi @osamakaram, we [really appreciate](https://community.sonarsource.com/guidelines#ai-generated-stuff) 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. ---
**Author:** ![osamakaram](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/osamakaram/32/78091_2.png) [@osamakaram](https://community.sonarsource.com/u/osamakaram)\ **Post date:** [November 13, 2026, 3:00am UTC](https://community.sonarsource.com/t/authenticated-sonarqube-cli-exits-51-without-a-visible-finding-inventory-after-server-upgrade/190757/4 "2026-11-13T03:00:38Z")
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? ```sh # 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" ```