Security and the October 2026 incident.
A site that sells website rescue should be able to explain its own recovery. This page records what happened, what was removed and what changed. It is deliberately factual: no claim that any site is unhackable, and no claim that a shared host is a fortress.
1. What happened
Between 3 and 5 October 2026, an attacker used backdoors placed in the hosting account. The files were not uploaded through a public form. The access logs point to another channel: FTP, cPanel File Manager, SSH credentials, or another site on the same shared account.
| Date (log time, UTC-4) | Activity |
|---|---|
| 3 Oct, 15:40 | First scan of /assets and /404; a backdoor was already present. |
| 3 Oct, 15:41 | Requests to /assets/css/senohprae2.1.php with POST bodies. |
| 4 Oct, 03:16–04:23 | Repeated POSTs to /cjfuns.php, a 2.3 MB response, requests to style.php, sitemap, and a ping to the sitemap. |
| 4 Oct, 04:05–04:23 | Directory-by-directory requests for index.php. |
| 4 Oct, 19:56 | Last observed reuse of the backdoor. |
Files recovered and quarantined: a webshell disguised as an asset (senohprae2.1.php), a spam/eval page (cjfuns.php), a backdoor loader disguised as a WordPress plugin, an obfuscated index.php loader and the zip-wrapper payload it included.
2. What was done
- Malicious files were removed from the deployed set and kept in quarantine outside the web root for analysis. They are not executable from the site.
- A clean baseline was created and placed under version control, so deployment no longer starts from an unknown file set.
- The public directory of prospect audits was removed. Client audit links are private.
- The old anti-DevTools script was removed. It did not improve security and it broke accessibility tools.
- Analytics was changed to load only after consent, reducing third-party data exposure for visitors.
3. What is in place now
- HTTPS with HSTS, a Content-Security-Policy,
X-Frame-Options,X-Content-Type-Optionsand a restrictive permissions policy. - Consent-gated Google Analytics and Meta Pixel; no tracking before a choice is made.
- Off-site backups and a version-controlled deploy path.
- No marketplace or prospect audit directory exposed on the public trust path.
4. Open items I am working through
- Confirming two-factor authentication on the hosting, registrar and email accounts.
- Quarterly access review and credential rotation schedule.
- File-integrity alerts on the deploy path.
- An incident-response checklist kept with the backups.
These are listed because a security page that only lists achievements is marketing, not a security page.
5. What a rescue engagement covers
- Preserve evidence before cleaning: logs, file hashes, timestamps.
- Find the entry point, not only the visible payload.
- Remove backdoors and reinfection vectors; reset credentials and keys.
- Harden the site, the CMS and the hosting account.
- Check search-engine and browser reputation; request review where a flag remains.
- Deliver a written report: what was found, what was removed, what changed, what to monitor.
Rescue work starts at €750. See pricing or the rescue process.
6. Report a security issue
If you believe this site or one of its endpoints is vulnerable, email contact@abdultsd.com with the URL and a short reproduction. I acknowledge security reports within two working days and will not pursue action against good-faith research.