Api Alarm Manager WP Registry grade D+. High-severity findings · 3 findingsWP RegistryHigh-severity findings · 3 findingsOpen the reportD+

High-severity findings.

Audited release

2.4.0

Findings

3

Worst severity

high

Content hash

60fca55ba690465db43be00b… Copy

Findings

• high Unauthenticated and Subscriber-reachable alarm import with no capability or nonce check

  missing_auth

  When FTP/SFTP import is configured (the plugin's intended production mode), Importer::addHooks() registers two unguarded entry points for the same privileged import(): (1) any request with query argument alarmimport hooks import() on init with no is_user_logged_in, current_user_can, or nonce check, so an unauthenticated GET to /?alarmimport=1 runs the importer; (2) wp_ajax_import_alarms is reachable by every logged-in role, including Subscriber, and the admin JS posts {action: 'import_alarms'} with no nonce. import() raises max_execution_time to 600, creates wp-content/uploads/alarms at mode 0777, copies every file listed on the remote host (not just XML) into that web-accessible directory using stored FTP credentials, parses XML into published alarm and station posts, updates api-alarm-manager-last-import, and when API_ALARM_MANAGER_ARCHIVE_ALARMS_ON_REMOTE is true moves remote files into the archive folder. A one-time path also blanks post_content on all existing alarm posts. The admin UI only shows the import button to administrators, but that check is not applied to either handler. Impact is unauthenticated integrity/availability abuse of the municipal alarm pipeline (DoS against FTP and PHP, forced content create/update, possible remote XML loss, arbitrary-file drop into uploads if the FTP tree is untrusted).

  source/php/Importer.php:20-39

  Recommendation

  Require manage_options (or a dedicated cap) and a CSRF nonce on both the GET trigger and wp_ajax_import_alarms. Remove the unauthenticated ?alarmimport= init hook; if a manual trigger is needed, keep it behind admin-post.php or AJAX with check_ajax_referer and current_user_can. Restrict remote copies to .xml, store them outside the web root, and do not mkdir 0777.

• medium Public fire-danger levels options page is writable by Contributor+ (edit_posts)

  missing_capability

  Admin\FireDangerLevels registers an ACF options page at menu slug fire-danger-levels with capability edit_posts. Contributors, Authors, and Editors can therefore change the fire_danger_levels repeater stored in options. Those values are the sole data source for the unauthenticated REST callbacks Api\FireDangerLevels::getFireDangerLevels and Api\AllDisturbances::getApiResponse (routes /wp/v2/fire-danger-levels and /all-disturbances), which city front-ends consume as official fire-ban status. FTP/API credentials on the sibling options page correctly require edit_users; fire-danger does not. A Contributor who cannot even publish posts can still poison the public emergency API.

  source/php/Admin/FireDangerLevels.php:16-29

  Recommendation

  Raise the options page capability to manage_options (or at least publish_posts / edit_others_posts) so only trusted operators can change publicly consumed fire-ban data.

• medium Global Cache-Control: public, max-age=300 overwrites logged-in nocache headers

  insecure_config

  PostTypes\Alarms hooks rssCacheControl to send_headers without an is_feed() guard. The callback always sends Cache-Control: max-age=300, public and a matching Expires header. WP::send_headers applies wp_get_nocache_headers() for logged-in users first, then fires send_headers, so this plugin overwrites WordPress's private/no-cache policy on every front-end request that reaches WP::send_headers (archives, singles, feeds, and any other non-REST query). Independently, Api\Disturbances::setCacheHeader() removes rest_send_cors_headers and sets Cache-Control: max-age=300 on rest_pre_serve_request for the entire REST API, not only disturbance routes. Shared caches that honor public (CDN 'cache everything', Varnish, nginx proxy_cache) may store and replay authenticated or user-specific HTML and REST responses for five minutes.

  source/php/PostTypes/Alarms.php:15-16, 63-66

  Recommendation

  Only send RSS cache headers inside is_feed() (and only for alarm feeds). Do not use the public directive on authenticated responses. Scope the REST Cache-Control filter to the plugin's own GET routes and send Cache-Control: public, max-age=300 only for unauthenticated GETs of public alarm data.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.