My first production finding: one debug flag, three outcomes

The first clue

I was testing ordinary search parameters when debug=1 made the page print the HTTP client’s connection log above the search results. It was not application data, but it exposed much more of the search setup than a public page needed to show.

GET /search?keywords=test&debug=1

Trying [backend IP]...
Connected to [Acquia search host]
POST /solr/[core name]/select
User-Agent: acquia_search/[version]

The output included the backend hostname and IP address, the Solr core path, request metadata, and the Acquia Search client version. I have left the live infrastructure values out of this write-up.

Following the exposed path

On some of the affected sites, the disclosed backend address was reachable directly. A Solr administration response could be requested as CSV. The response contained the search index’s field names: useful schema information, but not the indexed values.

GET https://[redacted-host]/solr/[redacted-core]/admin/ping?wt=csv

field_a,field_b,field_c,...

The collection names also followed a predictable pattern. I checked a limited number of adjacent names and confirmed that other collection schemas were reachable, then stopped rather than enumerate the full range. This separated two issues that were easy to overstate: the debug page exposed internal routing details, while the direct endpoint exposed field names. I did not retrieve indexed records, credentials, or server-side files.

The URL-controlled CSV text

Solr’s CSV response writer accepted formatting options in the query string. I confirmed that one of those options could place a controlled marker into the downloaded response.

GET /solr/[core]/admin/ping?wt=csv&csv.newline=[controlled marker]

field_a,field_b,field_c,...[controlled marker]

I also tested a spreadsheet formula / DDE-shaped value. In my test, the direct company-hosted URL produced a CSV that Windows handed to Excel without me renaming the file. Excel immediately displayed its trust prompt. Nothing executed silently—the user still had to approve—but the endpoint was serving attacker-controlled, potentially malicious spreadsheet content from the company’s own infrastructure. I understand the phishing or social-engineering objection, but the file-generation behavior itself was real.

Reports and outcomes

I found the same basic pattern on many Acquia-backed sites. The technical behavior was similar, but each program judged the impact differently.

• Mars VDP: resolved at low severity. This was my first valid production report.
• Nestlé: two submissions were closed as out of scope. The detailed report was recorded as High (7.2), but triage did not validate that severity; it closed the report under the rule for verbose output without sensitive information.
• U.S. Department of Justice / DEA: the disclosure was described as low impact and not accepted under the program’s scope because it did not expose sensitive information or perform a sensitive action.

I also emailed a number of site owners directly. Only one or two replied. Later checks showed that the exposed behavior had been removed, but I cannot know which changes, if any, came from my messages.

Why this one stayed with me

All three cases came from what felt like my first real finding in production. The primitive was almost identical, but the responses were not: one valid low, one extended out-of-scope discussion, and one short low-impact rejection. That taught me early that a working technical chain and a program-accepted impact are two different things.

It also happened just before AI-generated bulk reports became a constant concern in the bug-bounty ecosystem. I was lucky to get several distinct triage lessons from one small piece of research before the queues became even noisier.