AIMF Security · Website and hosting-layer defense

Website Defense Hub

Your website is its own attack surface: the CMS and its plugins, the PHP runtime actually executing your code, the hosting configuration behind the dashboard, and the CDN/WAF in front. This hub collects the defense resources for that layer — live vulnerability intelligence and incident lessons from our own infrastructure.

Workspace Defense covers your business applications and accounts. Network Defense covers your infrastructure. This hub covers the website itself.

Live intelligence · WordPress + Shopify

CMS Vulnerabilities

Current CVE feeds for WordPress core, plugins and themes, plus Shopify ecosystem components — with source-driven triage guidance and honest coverage limits.

A CVE disclosure identifies a reported vulnerability. It does not prove your site is affected or compromised.

Open the CMS feeds
Incident lesson · php2shell series, Part 1

The PHP Version Lie

Our hosting dashboard said PHP 8.3. The site was executing 8.1 — for two weeks after a "verified" upgrade. The full diagnosis, the .htaccess forensics, and a five-minute check for your own site.

The lesson generalizes: verify the runtime, not the dashboard. During the October 2026 php2shell wave, that gap was exactly where attackers lived.

Read the incident breakdown
Incident lesson · php2shell series, Part 2

Cloudflare Hardening for WordPress

The four-layer Cloudflare stack in front of WordPress — and the two configuration traps that produced rules which validated, deployed, showed Active, and matched nothing.

Part 1's verification habit applies here too: a rule that reports success is not a rule that matches traffic.

Read the hardening guide
Related · OS-level tracking

Device CVE Trackers

Operating-system and device vulnerabilities live in their own tracker hub — Windows, macOS, iPhone and Android. Keep website/CMS issues distinct from device issues.

Browse the device trackers

The verification habit

Every resource in this hub teaches the same discipline from a different angle:

  1. Read the runtime, not the report. Dashboards, banners and status pages describe intent. Site Health, feed data and rendered behavior describe fact.
  2. Check applicability before acting. A CVE name-match is not exposure; confirm the version range and prerequisites.
  3. Verify the fix landed. A settings change that reports success can leave the underlying configuration untouched — re-check against the executing system.

Want this handled for you?

We audit and harden the full website layer — CMS inventory, PHP runtime verification, hosting configuration and CDN/WAF rules — as standalone services.