Brightery File Lockdown
| 开发者 | brighterycom |
|---|---|
| 更新时间 | 2026年9月7日 00:28 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
- 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.
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.
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.
安装:
- 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.
常见问题:
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-plugins or 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.
更新日志:
- 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.
- 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.
- Updated compatibility metadata to WordPress 7.1.