Case study: an installation file left online opens a restaurant's back office

Key figures

Who is the company?

This is a restaurant (Client D, anonymized, domain client-d.example) with a custom-built showcase site that includes a booking and takeaway ordering module. There is no security team and no identified integrator. It is the typical situation of a very small business: the site was delivered one day and has not been reviewed since.

What were the scope and the authorization?

The flash report covers the showcase site and the bookings, with anonymous access first, then an administrator session obtained as proof. Written authorization precedes this kind of test. According to the report, the session was used only to confirm access, no booking was read and no change was made. The test sent no write request to the site, and the local session cookie was destroyed.

What did we find?

A single finding, but of High severity: a publicly accessible database installation file that exposes the default administrator account.

The report rates the likelihood of exploitation as frequent (three requests), the impact as high (customer data and takeover of the site) and the fix complexity as basic. Quick checks for other backups, configuration files and database management interfaces all came back negative.

How does the attack chain work?

It strings together three simple steps, with no advanced technique.

1. The installation file can be downloaded by anyone and responds normally. It contains the creation of the administrator account with its password hash.
2. That hash matches the sample value reused by many tutorials and frameworks. The associated plain-text password is therefore known to everyone, and it had never been replaced in production.
3. The administration panel accepts the login, which opens the dashboard.

The dashboard allows reading, editing and deleting every booking and order, with customers' names, phone numbers and email addresses. An attacker could also alter the menu and banners, or use the addresses for convincing phishing messages. The effect is equivalent to a controlled export of the business database. The default password is not reproduced here, and the report deliberately does not detail the administration paths.

What held up?

Little surface was exposed. The web server and language were conventional, no vulnerable CMS was identified, and searches for other backups, environment-variable files and database management tools all returned "not found". There was no public API. The problem came down to a single forgotten file and a single credential that was never changed. That is also what makes the fix quick.

What fixes do we recommend?

Complexity is basic, and the actions come in this order.

• Remove the installation file from the site's public root, and block access to backups and directory listings.
• Change the administrator password immediately to a long, unique value, and check the access logs to see whether the file has already been downloaded.
• Treat the account as compromised until that check is done: notify affected customers if illegitimate access is found.
• Set up a deployment that ships only the necessary files, not the whole project folder.
• Remove sample accounts and passwords from any installation script before going to production.

These practices map to the "security misconfiguration" category of the OWASP Top 10 and to the French regulator's guidance on personal data security, which calls for strict credential management and limited access. Email addresses and phone numbers in a booking book are personal data, which makes the exposure sensitive under GDPR.

What this changes for an AI agent

A restaurant has no AI agent in this particular case, but the pattern transfers directly. Many small teams now connect an agent to their back office to answer customers, confirm bookings or prepare orders. The agent then receives access, often administrator access, and inherits every weakness of that back office.

• An agent acts with the rights it is given. If the back office opens with a default account, whoever finds it also controls what the agent can read and change. See our guide to limiting excessive agency.
• Secrets must stay out of the public root. An installation file, an export, an environment-variable file or a repository history can contain keys for tools the agent uses. Our articles on secrets in repository history and public variables that expose secrets cover the risk.
• An agent reads personal data at scale. If it can list bookings, a prompt injection can make them leave. See our study of chatbot data leaks.
• Installation credentials are a classic. Before connecting an agent, check that no sample account remains in the tool it connects to.

This is the kind of check an AI agent red team puts first, before testing the agent itself: an agent is never safer than the system it drives. For the general framework, see our page on AI agent security. The same missing access control appears in our studies on an n8n webhook and a bypassable subscription, and in the AI writing SaaS case.

What was the outcome for the client?

The client received a flash report with the proven chain and a fix plan that takes a few minutes of work: remove the file, change the password, block backups. For a restaurant, this kind of fix needs no project and no budget. The takeaway is speed: a flaw avoidable in three requests needs no expertise to exploit, nor to close. If you want a second look at an agent connected to a business tool, our Agent Red Team Express offer starts at 1,900 euros over five days.

Other case studies

• n8n webhook: admin accounts opened
• Supabase paywall bypassed in two requests
• AI writing SaaS application
• Crypto-asset exchange platform