Shared hosting is cheap and easy — but when attackers compromise one account, every site on it falls. Here's how web shell attacks work and what schools can do instead.
In 2026, attackers breached two colleges in La Union simultaneously — not by hacking each one individually, but by compromising the single shared hosting account that ran both their websites. From that one account, the attackers exfiltrated 16+ database tables containing student payments, enrollment records, tuition fees, and user accounts with plaintext passwords. Both sites were defaced within minutes of each other.
This wasn't an isolated case. Shared hosting is the default choice for most Philippine schools — it's affordable, often bundled with a domain, and easy to set up. But it's also one of the most dangerous hosting models for institutions that store sensitive student data.
Shared hosting means your school's website lives on the same server as dozens — sometimes hundreds — of other websites. You all share the same CPU, memory, disk space, and often the same control panel (cPanel, Plesk, or similar).
Think of it like renting a room in an apartment building. You share the hallways, plumbing, and electrical system. If someone in another unit causes a flood, your unit gets wet too.
On shared hosting, a single compromised account can expose every site on that account — their files, databases, emails, and control panel access. If your school shares a hosting account with another site (or even another school), a breach on either one is a breach on both.
Based on real incidents tracked on SchoolBreach.org and evidence posted by threat actors themselves, here's how shared hosting attacks typically unfold:
Attackers scan for:
/wp-admin, /administrator, /cpanel with weak or default credentials.php files instead of just imagesA web shell is a small PHP file (often just a few kilobytes) that, once uploaded to your server, gives the attacker a full file manager and command terminal — accessible through their web browser.
Common web shell capabilities:
| Capability | What It Means |
|-----------|---------------|
| File browser | Browse, read, edit, and delete any file on the hosting account |
| File upload | Upload additional malware, backdoors, or defacement pages |
| Database access | Read database credentials from config files, then dump entire databases |
| Command execution | Run system commands as if they were logged into the server |
| PHP info viewer | See full server configuration, installed modules, and file paths |
Web shells have names like "Simple Shell," "WSO," "c99," or "b374k." They're freely available and widely documented. The barrier to entry is extremely low.
Once the attacker has a web shell, they look for configuration files that contain database passwords:
wp-config.php (WordPress).env files (Laravel, Node.js)configuration.php (Joomla)config/database.php (various frameworks)On shared hosting, these files are often readable by any script on the same account — meaning access to one site gives access to all databases on that account.
With database credentials in hand, the attacker exports the entire database to CSV or SQL files. In the La Union case, this included:
On shared hosting, the file manager shows all domains on the account. If your school shares hosting with another school or organization, the attacker can:
This is exactly what happened in the La Union breach — three domains were accessible from a single compromised account.
Finally, the attackers replace the homepage with a defacement banner claiming credit. By this point, the real damage (data exfiltration) is already done. The defacement is just the public announcement.
Watch for these signs:
x.php, shell.php, or 404.php that you didn't create/wp-content/uploads/, /tmp/, or any writable directoryOptions -Indexes to your .htaccess file so attackers can't browse your file structure| Hosting Type | Cost | Isolation | Risk Level | Best For |
|-------------|------|-----------|------------|----------|
| Shared hosting | P100–500/mo | None — all sites share everything | High | Brochure sites with no sensitive data |
| VPS (Virtual Private Server) | P500–2,000/mo | Your own virtual machine | Medium | Schools with student portals or databases |
| Managed WordPress hosting | P300–1,500/mo | Site-level isolation, automatic updates | Low-Medium | WordPress-based school sites |
| Cloud hosting (AWS, GCP, Azure) | P500–5,000/mo | Full isolation, enterprise security | Low | Schools with custom systems or large databases |
Our recommendation: If your school's website handles student data, enrollment, payments, or any personally identifiable information, do not use shared hosting. A basic VPS or managed hosting plan costs only marginally more and provides fundamental security isolation that shared hosting cannot.
If migrating isn't immediately possible:
The shared hosting attack pattern — upload shell, read configs, dump database, pivot to neighbors — is the most common methodology we've observed in hacktivist attacks against Philippine schools in 2025–2026. Groups like Nullsec Philippines and its affiliates have used this technique repeatedly, and they've publicly posted screenshots demonstrating the process.
This isn't a theoretical risk. It's happening now, and the tools required are freely available to anyone. The best defense is not to be on shared hosting in the first place — but if you are, the hardening steps above can significantly reduce your exposure.