ELEVENZEROServer Security AuditAugust 2026For Charlotte DeFazio-McElrath
musingsmag.com & susanrockefeller.com — Infrastructure Assessment

These servers haven’t been maintained since ~2021.
Every week they stay as-is is borrowed time.

Both websites run on unmanaged Digital Ocean droplets built on Ubuntu 16.04 — an operating system that lost security support over five years ago. The web server and WordPress installations are years behind their current versions, with dozens of documented vulnerabilities between them. A routine maintenance timer was never activated, leading directly to the recent SSL certificate failure.

Sites
musingsmag.com · susanrockefeller.com
Audit Type
Server security + infrastructure
Current Host
Digital Ocean (unmanaged)
Date
August 2026
91Known vulnerabilities
across both sites
5+Years without
OS security patches
12Critical/high-severity CVEs
discovered
4User accounts
publicly exposed
What’s broken

Outdated, exposed, unmonitored

  • 52known vulnerabilities in susanrockefeller.com’s WordPress 4.9.1 — including 9 rated critical or high severity.
  • 39known vulnerabilities in musingsmag.com’s WordPress 5.5.3 — including SQL injection and code execution flaws.
  • •nginx 1.10.3 (released January 2017) serves both sites — version exposed in every HTTP response. Current stable is 1.31.
  • •The PHP session cleanup timer was never started — the server filled its file index and couldn’t create new files, breaking SSL renewal and all updates.
What’s missing

Exposed and unhardened

  • 0security headers on either site — no Content-Security-Policy, no X-Frame-Options, no Strict-Transport-Security, no X-Content-Type-Options.
  • •The REST API exposes user accounts publicly on both sites — names and slugs visible to anyone.
  • •No TLS 1.3 support — both sites max out at TLS 1.2. Modern browsers work, but security scanners flag it.
  • •Server software versions are exposed in every HTTP response — nginx version, OS, and PHP session cookies are visible to any visitor.
What to do

Migrate to managed hosting

  • 1Move both sites to Kinsta — managed WordPress hosting with automatic updates, daily backups, free SSL, and 24/7 monitoring.
  • 2Update WordPress core and plugins during migration, testing for breaking changes in a staging environment.
  • 3Decommission the DO droplets once migration is verified — eliminating the unpatched attack surface entirely.

The plan, in order

Each phase is independently shippable. The goal: get off unmanaged infrastructure before something breaks that can’t be fixed.

01

Migrate both sites to Kinsta

Kinsta provides free migration assistance. Each site is moved to an isolated container with its own staging environment. WordPress core, PHP, and nginx are all managed and kept current by Kinsta — no server administration required.

SSL certificates are provisioned automatically via Cloudflare and renew without intervention. Daily backups are retained for 14 days.

~1–2 weeks including testing
02

Update and harden WordPress

Both sites need WordPress core updates (4.9.1 → current, 5.5.3 → current). Test in Kinsta’s staging environment first — the jump from 4.9 is large enough that theme and plugin compatibility needs verification before going live.

Add security headers via Kinsta’s configuration. Disable public user enumeration via the REST API. Review and update all plugins.

~1 week of testing and fixes
03

Decommission the DO droplets

Once both sites are verified on Kinsta, cancel the Digital Ocean droplets. This eliminates the unpatched Ubuntu 16.04 servers entirely — no more manually-managed infrastructure running years-old software.

Before decommissioning, archive a final backup of the droplet filesystem in case any non-WordPress assets need to be recovered later.

~1 day
What happened last week

The SSL failure is a symptom of a deeper problem

The recent certificate expiration on musingsmag.com traces back to a system maintenance failure that has been compounding since the server was first set up.

  • PHP sessions were never cleaned up. A built-in Ubuntu timer (phpsessionclean.timer) was configured but never started. Sessions accumulated for years.
  • The server’s file index filled completely. 3.9 million inode slots — 100% consumed. The disk had 34 GB free but couldn’t create a single new file.
  • SSL renewal crashed. Certbot tried to renew the Let’s Encrypt certificate, couldn’t write a temporary log file, and exited with No space left on device. The certificate expired.
  • WordPress updates were blocked too. Plugin installs, core updates, and file uploads all fail for the same reason — the server cannot write to disk.

Read more, if you want the receipts

Software versions detected externallyBoth sites
Componentmusingsmag.comsusanrockefeller.comCurrent stable
Ubuntu16.04 (EOL April 2021)16.04 (EOL April 2021)24.04 LTS
WordPress5.5.3 (Oct 2020)4.9.1 (Nov 2017)7.0.2
nginx1.10.3 (Jan 2017)1.10.3 (Jan 2017)1.31
PHP*Likely 7.0 (EOL Dec 2018)Likely 7.0 (EOL Dec 2018)8.3+
jQuery (bundled)1.12.43.2.13.7+
Certbot0.31.0 (2019)Unknown3.x

*PHP version inferred from Ubuntu 16.04 default; root access required to confirm directly.

WordPress vulnerabilities by severityCombined

Source: WPScan 4.9.1 and WPScan 5.5.3

SiteWP VersionCritical / HighMediumLowTotal
susanrockefeller.com4.9.1938552
musingsmag.com5.5.3330539

Critical / high-severity examples (susanrockefeller.com)

  • PHP Object Injection via Meta Data (CVSS 9.8)
  • wp_kses_bad_protocol() Colon Bypass (CVSS 9.8)
  • Server-Side Request Forgery in URL Validation (CVSS 9.8)
  • SQL Injection via WP_Query (CVSS 8.6)
  • Authenticated Code Execution (CVSS 8.8)
Publicly exposed informationBoth sites

The WordPress REST API is publicly accessible on both sites and exposes user account information without authentication.

musingsmag.com — /wp-json/wp/v2/users

IDNameSlug
25Annabel Schulzannabel-schulz
22Charlotte DeFaziocharlotte
7Jane Ratcliffejratcliffe
3Susan Rockefellersusan

susanrockefeller.com — /wp-json/wp/v2/users

IDNameSlug
3charlottecharlotte

User slugs are often identical to login usernames. Combined with the exposed wp-login.php on both sites, this gives an attacker half of what they need for a brute-force login attempt.

What Kinsta manages that Digital Ocean does notComparison
CapabilityCurrent (DO unmanaged)Kinsta managed
OS patchingManual — Ubuntu 16.04 EOL since April 2021Automatic
PHP updatesManual — likely running EOL PHP 7.0*Managed, multiple versions available
WordPress core updatesManual — currently blocked by server issuesAutomatic with visual regression testing
Plugin updatesManual — currently blocked by server issuesAutomatic with rollback on failure
SSL certificatesCertbot (recently failed, required manual fix)Free wildcard SSL, automatic renewal
BackupsDO droplet backups enabled (daily)Daily, retained 14 days
Malware scanningNot included with DO dropletsContinuous + free removal
DDoS protectionNot verifiedCloudflare enterprise-grade
FirewallNot verifiedCloudflare WAF
Security headersNone configured (verified)Configurable via dashboard
Staging environmentManual copy on same serverOne-click per site
ComplianceNot applicable (unmanaged)SOC 2 Type II, ISO 27001

*PHP version inferred from Ubuntu 16.04 default; root access required to confirm.

How this audit was conductedMethodology

This audit was performed externally using standard reconnaissance techniques available to any attacker. No exploitation was attempted.

Methods

  • HTTP response headers were captured via direct HTTPS requests to both domains.
  • WordPress versions were identified from the RSS feed generator tag and asset version strings in page source.
  • nginx version was read from the Server response header.
  • SSL/TLS configuration was tested via openssl s_client against each supported protocol version.
  • User enumeration was performed via the public WordPress REST API (/wp-json/wp/v2/users).
  • Vulnerability counts were sourced from the WPScan vulnerability database.
  • Server-side investigation (inode exhaustion, session cleanup, certbot failure) was conducted via SSH as a non-root user with read-only filesystem access.

Limitations

  • PHP version was inferred from the OS default (Ubuntu 16.04 ships PHP 7.0) and WordPress compatibility. Direct confirmation requires root access.
  • nginx CVE count is limited to what nginx.org’s own advisory page lists; additional vulnerabilities in Ubuntu’s patched distribution packages may exist.
  • No authenticated WordPress scanning was performed — plugin-specific vulnerabilities beyond what’s visible in page source are not cataloged here.