High-severity findings.

Audited release

2.3.8

Findings

6

Worst severity

high

Content hash

a43ba215a5424510a6490824… Copy

Findings

• high Subscriber can run AI site generation and publish posts

  missing_capability

  POST /wp-json/newfold-ai/v1/search, /search/default, /search/sitegen, /search/homepages, and /search/otherpages use permission_callback check_permission, which is only current_user_can('read'). A Subscriber or Customer therefore passes. The inner SiteGen::check_capabilities and AISearchUtil::check_capabilities test Hiive site flags (hasAISiteGen, canAccessHelpCenter), not a user role. When hasAISiteGen is true, sitegen calls SiteGen::generate_site_meta. On PHP 7.4 (the plugin Requires PHP line) the two-argument call still enters the function: identifier is not restricted to the validation map, the response is stored with update_option('nfd-ai-site-gen-' . identifier), identifier siteclassification calls generate_site_posts which wp_insert_post()s six publish posts whose titles and excerpts come from the AI response, and the always-registered hook newfold/ai/sitemeta-siteconfig:generated runs set_site_title_and_tagline, which update_option()s the blog name and tagline. The front end then shows that title and those posts. On PHP 8+ the sitegen/homepages/otherpages calls throw ArgumentCountError before SiteGen runs, so that write path does not complete; /search and /search/default still run, send the site Hiive bearer token to hiive.cloud, and return the AI payload to the Subscriber whenever canAccessHelpCenter is true. A nonce is not required beyond the REST cookie nonce any logged-in user can mint.

  vendor/newfold-labs/wp-module-ai/includes/RestApi/AISearchController.php:155-161,275-284

  Recommendation

  Require manage_options (or a dedicated sitegen capability) in check_permission, allowlist identifier before any option write or do_action, and stop publishing posts or changing blogname from this route. Align the REST call with generate_site_meta's required arguments.

• high Editor can set the homepage and update any post by ID

  missing_capability

  The AI Page Designer proxy routes (list, get, create, update, and POST /homepage/{id}) use CapabilityGate::rest_permission, which requires edit_pages plus the site flags canAccessAI and canAccessAIPageDesigner. An Editor passes; a Subscriber does not. set_homepage then update_option('show_on_front', 'page') and update_option('page_on_front', $id) with no manage_options check. WordPress uses those options to choose the front page, so the Editor changes what every visitor sees. update_content and get_content load any post ID via get_post and wp_update_post without current_user_can('edit_post', $id) and without checking that the post type matches the route. wp_update_post does not enforce caps. An Editor can change title, content, slug, and status of another user's private content and of other post types, including WooCommerce shop orders, and create_content will publish pages or posts as that user. Content is passed through wp_kses_post, so this is not a script-tag bypass, but the homepage and the updated post are what the front end renders.

  vendor/newfold-labs/wp-module-ai-page-designer/includes/RestApi/WordPressProxyController.php:290-372

  Recommendation

  Require manage_options for set_homepage. For create, update, and get, call current_user_can( 'edit_post', $id ) or the matching create cap, and reject IDs whose post type is not the route type.

• medium Any logged-in user bypasses the coming soon page

  missing_capability

  When nfd_coming_soon is on, maybe_load_template on template_redirect shows the coming-soon template only if the visitor is logged out, or if the query string is exactly preview=coming_soon. A Subscriber, Customer, Author, or Editor is logged in, so the condition fails and the real theme renders the unpublished site. No manage_options check exists. The coming-soon REST enable/disable routes do require manage_options, and the public subscribe action checks the page nonce before calling Jetpack, so this finding is the read of the hidden site, not a settings write.

  vendor/newfold-labs/wp-module-coming-soon/includes/ComingSoon.php:340-346

  Recommendation

  Treat only users who can manage_options (or edit_posts, if contributors must build) as exempt from the coming soon template. Keep subscribers and customers on the interstitial.

• medium Author can optimize or replace any attachment

  missing_capability

  POST /wp-json/newfold-performance/v1/images/optimize allows any user with upload_files (Author, Editor, Shop Manager). It does not check edit_post on the attachment. The handler loads get_attached_file and wp_get_attachment_url for the supplied media_id, sends that URL to ImageService::optimize_image, and then either replaces the original with a webp (when auto-delete is on) or registers a new media item. An Author can therefore modify or delete another user's upload. The media URL is what the front end serves afterward.

  vendor/newfold-labs/wp-module-performance/includes/Images/RestApi/ImagesController.php:47-67,76-110

  Recommendation

  Require current_user_can( 'edit_post', $media_id ) in addition to upload_files, and confirm the attachment is an image the user is allowed to edit before calling the optimizer or deleting the original.

• medium Subscriber can submit Hiive events and read the notification response

  missing_capability

  POST /wp-json/newfold-data/v1/events and /events/batch use create_item_permissions_check, which is only current_user_can('read'). A Subscriber or Customer can queue arbitrary category, action, and data objects into the nfd event queue (serialized Event rows). With queue=false, create_item calls HiiveConnection::send_event, which posts the event plus core site data to Hiive using the site bearer token and returns the notification payload (id, locations, content) in the REST response. That payload is the hosting account's notice content, not the caller's. It does not by itself change WordPress options; the consumer is the JSON response and the Hiive-side notification list.

  vendor/newfold-labs/wp-module-data/includes/API/Events.php:119-172

  Recommendation

  Require manage_options for event creation, or at least for queue=false so a Subscriber cannot read Hiive notification bodies or spend the site token.

• low Feature list REST routes are unauthenticated

  missing_permission_callback

  GET /wp-json/newfold-features/v1/features and /feature/isEnabled use checkPermission, which always returns true. Any visitor learns which Newfold features are registered and whether each is enabled. Enable and disable still call Feature::canToggle, which is current_user_can('manage_options'), so an unauthenticated or Subscriber request cannot flip a feature; the REST layer returns 403 after that inner check. The observable effect is disclosure of the feature map, not a settings change.

  vendor/newfold-labs/wp-module-features/includes/FeaturesAPI.php:47-54,121-144

  Recommendation

  Make checkPermission require manage_options for every feature route, including the reads, instead of relying on the later canToggle filter.

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.