Index of /everything

Introduction

Anyone who has spent time on the web recognises that plain, unstyled grey page: a bare list of files and folders under a heading that reads Index of /. For years it was part of the scenery. Web servers that could not find an index file (index.html, index.php,…) and had directory listing enabled would simply hand back the contents of the folder.

On Apache this is mod_autoindex, and for a long time it shipped enabled by default. It was convenient for sharing files internally, and precisely for that reason it ended up exposed to the whole Internet countless times. There was an era when a simple Google dork, intitle:"index of", was an absolute classic of the reconnaissance phase.

You would expect that in 2026 this is history. It is not. This post looks at how open directory listings are still a reliable way to walk straight into confidential data, using nothing more than a browser, and why the problem is less about an exotic vulnerability and more about the same misconfigurations repeating themselves.

All findings described here were reported to CERT.PT prior to publication. Every screenshot is redacted, and no hosts, addresses, paths or credentials are disclosed. The goal is to illustrate the class of exposure, not to identify or facilitate access to any specific system.

Concepts

Before the findings, it is worth being precise about what directory listing actually is, because the listing itself is rarely the real problem.

Directory Listing (Autoindex)

When a web server receives a request for a directory rather than a specific file, it has two choices: serve a default index document, or generate a listing of whatever is inside that directory. The second behaviour, autoindexing, is what produces the familiar Index of / page.

On its own, an index page is not a vulnerability. If the directory only contains files that are meant to be public, exposing the listing changes nothing. The problem begins when the listing reveals files that were never supposed to be reachable over HTTP in the first place, database dumps, backups, configuration files, internal documents, and so on.

In other words, directory listing is almost always a symptom. It makes a pre-existing mistake, sensitive files living under the web root, trivially discoverable.

Information Disclosure as an Attack Vector

Information disclosure is often treated as a low-severity finding, but it sits at the start of two very different kill chains:

As an initial access vector, when the exposed files contain secrets, credentials, connection strings or API keys that let an attacker pivot from “standing at the door” to holding a real foothold inside the infrastructure.
As an exfiltration vector, when the exposed files are the sensitive data. Nothing needs to be broken into; the listing is the leak. The access often looks like perfectly ordinary GET requests in the logs.

Both of these showed up in the sample I looked at.

The Hunt

The methodology here is deliberately boring, which is part of the point. No exploitation, no fuzzing, no authentication bypass. Just a query.

Using Shodan, I scoped the search to Portugal and to servers that advertise this exact behaviour in their HTTP title:

country:PT http.title:"Index of /"

This returned more than 500 hosts exposing open directory listings in Portugal alone.

Most of them are harmless, serving public and uninteresting files. But a manual review of a sample revealed a consistent and far less comfortable pattern.

Findings

Before listing what turned up, some context on scope. The intent of this research was purely to demonstrate that the problem still exists, not to run an exhaustive campaign.

The hunting phase took only a few hours. I have little doubt that spending several days digging through these hosts would surface a great deal more, exposed admin dashboards, cPanel instances, phpMyAdmin panels and similar interfaces, on top of the raw file exposure described below.

What follows is therefore a shallow sample, not the bottom of the barrel. Without authentication, without exploitation, and with nothing beyond a browser, it was possible to reach, across different hosts.

PII

Full backups

Cleartext credentials

Why This Still Happens in 2026

A few recurring causes explain how we keep ending up here:

Forgotten defaults on servers stood up in a hurry, or on subdomains and non-standard ports that drift off the team’s radar.
“Working folders” under the web root, where someone drops a dump or a backup “just for a minute” and it stays there for years.
Shadow IT and legacy services, machines nobody claims ownership of until they turn up in a scan.
“Vibe coding” without the ops part. A new generation of builders is shipping apps assembled from AI-generated snippets, tutorials and copy-pasted configs, often with little idea of what the server underneath is doing. The app works, so it goes live, and nobody ever ran through the basics: disabling directory listing, keeping dumps and .env files out of the web root, locking down default configs. Getting something online has never been easier; understanding what you just exposed has not kept up.
No inventory and no external monitoring of the organisation’s own attack surface. If a researcher finds it on a quiet afternoon, so does an attacker.

Mitigation

The fix is as old and cheap as the problem:

Disable directory listing by default. On Apache, Options -Indexes; on nginx, confirm autoindex off; (it is the default, but confirm it).
Get everything that is not meant to be served out of the web root. Dumps, backups, .sql, .zip, .env and configuration files do not belong in an HTTP-reachable directory.
Authenticate what must stay private, and never pass secrets in URL parameters.
Scan your own external surface regularly, with Shodan, Censys, or internal tooling.
Review subdomains, alternative ports and legacy services, which is exactly where this tends to hide.

Conclusion

The Index of / page is almost a museum piece, and that is precisely why it is still dangerous. It is old enough that hardly anyone remembers to look for it anymore, yet it stays switched on across hundreds of servers, waiting.

The good news is that the remediation is equally old and trivial. The only thing missing is someone going in to turn it off.