Description
Brightery File Lockdown reduces the impact of a compromised WordPress administrator account by restricting high-risk code and upload capabilities.
In standard plugin mode it:
- Disables theme and plugin source-editing capabilities.
- Blocks installation of new plugins and themes from wp-admin.
- Blocks plugin and theme ZIP uploads.
- Blocks plugin and theme deletion from wp-admin.
- Keeps core, plugin, and theme updates configurable.
- Restricts uploads to an explicit image, audio, and video allowlist.
- Rejects executable, script, archive, and configuration-file extensions.
- Rejects suspicious double extensions such as
example.php.jpg. - Uses WordPress file-type validation plus server-side MIME detection when available.
- Applies the same upload checks to normal uploads and sideloaded uploads.
- Keeps a bounded local record of the latest 100 blocked security events in the WordPress database.
The plugin does not contact Brightery or any external service, does not send telemetry, and does not collect IP addresses or WordPress user IDs.
Admin-resistant Must-Use mode
A normal WordPress plugin can always be deactivated by an administrator. If your security goal is to remain active after a WordPress administrator account is compromised, use the optional Must-Use loader included in the mu directory.
For WordPress.org transparency and normal plugin lifecycle behavior, Brightery File Lockdown does not copy or install itself into wp-content/mu-plugins automatically.
A trusted server administrator may manually deploy the Must-Use mode using two files from this package:
- Copy
mu/brightery-file-lockdown-mu-loader.phptowp-content/mu-plugins/brightery-file-lockdown.php. - Create
wp-content/mu-plugins/brightery-file-lockdown/and copyincludes/class-brightery-file-lockdown.phpinto that directory asclass-brightery-file-lockdown.php.
The deployed MU loader resolves the copied engine relative to the loader’s own location. It does not rely on WP_PLUGIN_DIR or the normal plugin directory name. This lets the Must-Use protection continue loading even if the normal plugin is deactivated or its directory is renamed.
Remove both manually deployed Must-Use files with trusted filesystem access before uninstalling the normal plugin.
This plugin is a hardening layer, not a guarantee against compromise. Keep WordPress, plugins, themes, PHP, and the web server updated and apply server-level upload execution restrictions where appropriate.
Privacy
Brightery File Lockdown does not transmit data to external servers and does not collect IP addresses or WordPress user IDs. A bounded local event record may contain blocked filenames, MIME types, block reasons, and timestamps.
Screenshots
Installation
- Upload and activate Brightery File Lockdown normally from Plugins > Add New.
- Test normal media uploads and your update workflow.
- Apply the appropriate Apache or Nginx uploads rule from the included
serverdirectory. - For admin-resistant protection, manually deploy the optional MU loader and its engine copy using trusted hosting, SSH, SFTP, or deployment access.
- Review
wp-config-example.txtfor optional server-side configuration.
FAQ
-
Can a WordPress administrator deactivate the plugin?
-
In standard mode, yes. This respects the normal WordPress plugin lifecycle. For a compromised-admin threat model, manually deploy the included MU loader and engine copy using trusted server access.
-
Does the plugin automatically write files outside its own directory?
-
No. The WordPress.org package does not automatically create or modify files in
wp-content/mu-pluginsor other content directories. -
Why does Must-Use mode require two files?
-
The Must-Use loader is intentionally independent of the normal plugin directory. Deploying a copy of the engine beside the loader means the loader does not hardcode the normal plugin folder or rely on
WP_PLUGIN_DIR. -
Does this block normal media uploads?
-
Common image, audio, and video formats remain allowed. PDF is disabled by default and can be explicitly enabled in
wp-config.php. -
Are plugin and theme updates blocked?
-
Updates are allowed by default. They can be disabled through server-side configuration constants when a site owner intentionally wants a stricter immutable-code workflow.
-
Does the plugin send data to Brightery?
-
No. There are no telemetry, tracking, remote API, license-check, or external service calls.
-
Where are security events stored?
-
The latest 100 blocked events are kept in a non-autoloaded WordPress option on the local site. Entries can contain the blocked filename, claimed MIME type, reason, and event time. IP addresses and user IDs are not collected.
-
What happens to locally stored events when the plugin is uninstalled?
-
The plugin removes its local blocked-event option during normal WordPress uninstall. Any manually deployed Must-Use files must be removed separately using trusted filesystem access.
Reviews
There are no reviews for this plugin.
Contributors & Developers
“Brightery File Lockdown” is open source software. The following people have contributed to this plugin.
Contributors
Translate “Brightery File Lockdown” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
1.0.9
- Updated the Contributors field to the WordPress.org owner username
brighterycom. - Defined the normal plugin location from
__FILE__andplugin_dir_path()instead of relying on implicit paths. - Reworked optional Must-Use deployment so the loader resolves a separately deployed engine relative to its own location.
- Removed the Must-Use loader dependency on
WP_PLUGIN_DIRand the normal plugin folder slug. - Added uninstall cleanup for the locally stored blocked-event option.
1.0.8
- Removed automatic writes to the Must-Use plugin directory from the WordPress.org build.
- Replaced file-based logging with a bounded local WordPress option.
- Removed direct PHP filesystem operations flagged by Plugin Check.
- Removed direct request-action inspection that generated nonce warnings.
- Removed runtime definition of the WordPress
DISALLOW_FILE_EDITconstant; it is now documented as optional server configuration. - Removed IP/user actor logging.
- Added an explicit manual MU-loader workflow for administrator-resistant deployments.
- Retained WordPress 7.1 compatibility metadata.
1.0.7
- Updated compatibility metadata to WordPress 7.1.