Carlos A. Rojas

A javascript-free experience!

Taking Over a Website Using Disguised WordPress Plugins

LACTF — Los Angeles, 2026

Confirmed

Abstract

This session examines how WordPress sites can be fully taken over when an attacker is able to get server-side PHP of their choosing to execute within the application — most commonly by abusing the plugin mechanism, since plugins are, by design, arbitrary PHP that WordPress loads and runs. The talk walks through realistic avenues (a malicious or backdoored plugin, an upload path that lands executable PHP, or an unpatched flaw in a trusted plugin) and shows why “install a plugin” is functionally equivalent to “run code on the server as the web-server user.”

Key concepts

  • Plugin trust and execution context. A WordPress plugin is PHP that runs with the privileges of the web-server process. There is no sandbox between a plugin and the rest of the application.
  • Prerequisites matter. Dropping a malicious plugin usually presupposes something first: admin access to wp-admin, a vulnerable upload/installation path, or a separate flaw. Those preconditions are part of the story, not an afterthought.
  • Persistence. Plugin code, scheduled events (wp-cron), and modified core files are classic persistence footholds.
  • Monitoring, containment, recovery. File-integrity monitoring, least privilege on the web directory, and a known-good restore path are what turn a compromise into an incident you can actually recover from.

Application vs. server compromise

A recurring theme: compromising the WordPress application is not the same as compromising the underlying server. Executing PHP as the web-server user can give full control of the site and its database, but reaching root on the host is a separate step that requires a further privilege-escalation flaw or misconfiguration. The talk is explicit about which boundary each technique crosses, rather than implying that site takeover automatically means server takeover.

Defensive checklist

  • Install plugins only from trusted sources; review before enabling.
  • Keep core, themes, and plugins patched; remove unused ones entirely.
  • Restrict who holds administrator and plugin-install capabilities.
  • Make the web directory non-writable by the web-server user where possible; disable file editing (DISALLOW_FILE_EDIT) and uncontrolled plugin installs.
  • Deploy file-integrity monitoring and alert on changes under wp-content.
  • Maintain tested, offline backups and a documented restore procedure.

Companion lab

The concepts here are best explored safely in the disposable web app lab, which keeps any deliberately vulnerable component on an isolated, destroyable network.

Materials

No slide deck or lab archive is published here yet. Downloadable materials will be added only when the actual files exist and are cleared for release. No external links, recordings, or attendance figures are claimed.

Related