We receive support tickets every month from administrators who chose Panelica specifically for its security features — five-layer isolation, built-in WAF, fail2ban integration, OpsAI-assisted hardening — and then experienced a security incident despite having all of those features enabled.
In every single case, the breach did not happen because the panel failed. It happened because a human decision — or the absence of one — created an opening that no software could close.
This article documents seven real patterns we see repeatedly. Not to assign blame. But to help you avoid the same mistakes. Because we genuinely care about the security of servers running our software, and the most honest thing we can do is tell you where the real risks are.
A note from our team: We debated publishing this article. Some on the team felt it might undermine confidence in our product. We decided transparency serves our users better than silence. If you understand the limits of any panel — ours included — you will make better security decisions.
Mistake 1: The Password That Was "Good Enough"
admin / Company2024!
A hosting company with 200 client sites uses a pattern for database passwords: company name + year + exclamation mark. Every database on the server follows this pattern.
What happened: One client's WordPress site was compromised through an outdated plugin. The attacker found wp-config.php, which contained the database password "ClientName2024!" They noticed the pattern. Within hours, they had tried variations against every other database on the server. Twelve databases were accessed. Client data was exfiltrated. The hosting company spent six weeks on incident response and legal notifications.
What the panel provided (but was not used): Panelica generates cryptographically random database passwords by default. The admin overrode them with "memorable" passwords because they wanted to "easily access databases from phpMyAdmin without looking up credentials."
Estimated cost: $47,000 in incident response, legal fees, and lost clients.
┌─────────────────────────────────────────────────────────────────┐
│ PASSWORD ANTI-PATTERNS │
│ │
│ ✗ company2024! Pattern-based (predictable) │
│ ✗ Welcome1 Default / commonly used │
│ ✗ same-as-email Credential reuse across services │
│ ✗ written-in-slack Shared via insecure channels │
│ ✗ p@ssw0rd Leetspeak substitution (trivial) │
│ │
│ ✓ dK8$mN2!vX9pLq3@ Random 16+ characters │
│ ✓ panel-generated Let the panel create credentials │
│ ✓ password-manager Store in Bitwarden/1Password │
│ ✓ unique-per-service Never reuse across databases/sites │
│ ✓ 2FA-everywhere Password alone is never enough │
│ │
└─────────────────────────────────────────────────────────────────┘
Mistake 2: The Update That Could Wait
"We will update after the holiday season"
An e-commerce hosting provider delays WordPress core and plugin updates during their busiest sales period. "Too risky to update during peak traffic."
What happened: A critical vulnerability in WooCommerce was disclosed on November 28 (CVE published, patch available). The admin scheduled the update for January 15 — "after the holidays." On December 12, automated scanners found and exploited the vulnerability. Three stores were compromised. Customer payment information was exposed. The admin had to perform emergency updates anyway, during peak traffic, in crisis mode instead of planned maintenance mode.
What the panel could have done: Panelica's OpsAI can stage updates: "Update WooCommerce on staging first, verify checkout flow, then apply to production during the 3 AM low-traffic window." The panel also supports automated backup before any WordPress update — making rollback immediate if something breaks.
Estimated cost: $180,000 in PCI compliance fines, forensic investigation, and credit monitoring for affected customers.
"The most expensive update is the one you did not apply. The second most expensive is the one you applied without testing."
— Security operations wisdom
Mistake 3: The Test Server That Became Production
"It is just a staging server — security can wait"
A development team spins up a Panelica server for staging. They disable the firewall ("too many rules interfere with debugging"), use simple passwords ("it is just dev"), skip SSL ("no real users will see it"), and leave debug mode on in every application.
Note: OpsAI is powered by Claude Code (Anthropic). A Claude Code API key is required to use this feature. You can configure your API key in System Tools → OpsAI → Settings.
What happened: The staging server, initially at test.company.com, gradually accumulated production data for "realistic testing." Then the primary server had a hardware failure. Under pressure, the team pointed the production domain at the staging server — "temporarily." Temporarily became permanently. Six months later, the staging server — with its disabled firewall, simple passwords, no SSL, and debug mode exposing stack traces — was the production server serving 50,000 users.
What should have happened: Every server should be configured as if it will become production, because eventually many of them do. The panel's default security settings (firewall enabled, isolation active, SSL required) should never be disabled "for convenience."
Estimated cost: Immeasurable. The server was silently leaking debug information (database queries, file paths, internal IPs) for months before someone noticed.
Mistake 4: The Backup That Existed on Paper
"Backups run every night — I set it up months ago"
An administrator configures daily backups in the Panelica panel and moves on to other tasks. The backup job runs successfully for three months. Then the backup disk fills up. Backups silently fail. The panel shows a warning in the dashboard. Nobody checks the dashboard.
What happened: Eight months after backups stopped, a database corruption event occurs. The admin attempts to restore. The most recent backup is 8 months old. Eight months of user data, content, orders, and configurations — gone. The business lost everything created in that period.
Lessons:
- A backup that has never been restored is not a backup — it is a hope
- Configure backup failure email notifications — and actually read them
- Test a restore at least once per month
- Monitor backup storage capacity — set an alert at 80%
- Maintain at least one offsite copy in a different geographic location
Estimated cost: 8 months of data. For some businesses, this is an extinction event.
┌─────────────────────────────────────────────────────────────────┐
│ THE BACKUP VERIFICATION CYCLE │
│ │
│ ┌──────────┐ │
│ │ Schedule │─── Configure automated daily/weekly backups │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ Monitor │─── Check dashboard weekly, read alert emails │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ Test │─── Restore to test env monthly, verify data │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ Offsite │─── Copy to separate location/provider │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │Document │─── RTO/RPO targets, restore procedure │
│ └────┬─────┘ │
│ │ │
│ └─────────── Repeat monthly ──────────────────────┐ │
│ │ │
│ Every month. No exceptions. No shortcuts. │ │
│ │
└─────────────────────────────────────────────────────────────────┘
Mistake 5: The Open Port Nobody Remembered
"I opened port 9200 for Elasticsearch debugging last Tuesday"
A developer opens port 9200 to access Elasticsearch from their local machine for debugging. They complete the debugging. They forget to close the port. Elasticsearch has no authentication configured.
What happened: An automated scanner found the open Elasticsearch port within 6 hours. The attacker queried the indices, found customer data (names, emails, order history), and held the data for ransom. The developer had opened the port through the panel's firewall manager — the action was logged, but nobody reviewed the logs.
Prevention: Use OpsAI for periodic audits: "List all open ports and explain why each one is open. Flag any that are not standard web hosting ports." Or better: never expose database/search services to the internet. Use SSH tunnels for remote debugging.
Estimated cost: $25,000 in ransom negotiation, forensic investigation, and GDPR notification to affected customers.
Mistake 6: The Docker Image from an Unknown Source
"The Docker Hub image had 10K pulls — it must be safe"
An admin deploys a Docker container using an unofficial image from Docker Hub. The image contains a cryptocurrency miner that activates after 48 hours of uptime.
What happened: The container ran normally for two days, then began consuming 100% of its allocated CPU for cryptocurrency mining. Because Panelica's Cgroups v2 isolation limited the container to its plan allocation, the miner could not affect other users. But the admin's client was paying for compute resources that were being stolen. The admin noticed only when the client complained about slow performance — two weeks later.
Lessons:
- Only use official images from verified publishers
- Scan images before deployment (Trivy, Snyk)
- Monitor container CPU usage — sustained 100% is a red flag
- Panelica's Cgroups isolation limited damage, but the admin should have caught it earlier
Estimated cost: 2 weeks of stolen compute resources + client trust damage.
Mistake 7: The Admin Account That Outlived Its Owner
"We will clean up access after the project wraps up"
A freelance developer is given ROOT-level access to a Panelica server for a 3-month project. The project ends. The developer's account remains active. Eight months later, the developer's email is compromised in an unrelated breach. The attacker finds the panel URL and credentials in the developer's saved passwords.
What happened: The attacker logged into the panel with ROOT privileges. They created a new admin account as a backdoor, modified firewall rules to allow their IP, and downloaded a full server backup containing every client's data. By the time the breach was discovered, the attacker had been inside the system for three weeks.
What should have happened:
- Create time-limited accounts (the panel supports setting access expiry)
- Use ADMIN role instead of ROOT for external contractors
- Revoke access immediately when a contract ends — on the last day, not "next week"
- Enable 2FA for all admin accounts — the compromised password alone would not have been sufficient
- Review active admin accounts monthly
Estimated cost: Complete data breach of all clients. Business-ending for many hosting companies.
8. The Pattern — And How to Break It
Every mistake above shares a common structure:
┌─────────────────────────────────────────────────────────────────┐
│ THE BREACH PATTERN │
│ │
│ ┌──────────────┐ │
│ │ A correct │ The panel has the right feature. │
│ │ tool exists │ Firewall, backup, isolation, RBAC. │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ A human │ Override default password. Skip update. │
│ │ decision │ Open a port. Forget to revoke access. │
│ │ weakens it │ Trust an unverified image. │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Time passes │ The weakness is not immediately │
│ │ without │ exploited. No one notices. The │
│ │ review │ decision becomes the status quo. │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ An attacker │ Automated scanners, credential │
│ │ finds the │ databases, or targeted research │
│ │ weakness │ discovers the gap. │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ BREACH │ Damage proportional to how long │
│ │ │ the weakness existed unreviewed. │
│ └──────────────┘ │
│ │
│ SOLUTION: Regular review cycles break the pattern. │
│ The panel provides the visibility. You provide the review. │
│ │
└─────────────────────────────────────────────────────────────────┘
The solution is not more features. It is regular review. A monthly security audit — even 30 minutes — catches every one of these patterns before they become breaches.
Use OpsAI as your audit partner. Once a month, ask: "Run a comprehensive security review. Check for: unused accounts, expired credentials, open non-standard ports, failed backup jobs, outdated WordPress installations, unmonitored Docker containers, and firewall rules that have not been reviewed in 90 days." The AI does the scanning. You make the decisions about what to fix and how.
The Best Security Feature Is a Vigilant Administrator
We build the strongest tools we can. But the most secure Panelica servers are the ones managed by administrators who check, review, and improve — regularly.
Explore Panelica Security
Panelica — honest about what we can do, and honest about what only you can do.