Description

The Post Grid and Gutenberg Blocks – ComboBlocks plugin for WordPress is vulnerable to Unauthenticated Hook Injection in versions 2.2.32 to 2.3.1 via several functions in the ~/includes/blocks/form-wrap/function.php file. This makes it possible for unauthenticated attackers to execute actions with hooks in WordPress, granted no other security controls are present in the function.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-05T09:16:48.880Z",
  "pubdate": "2026-09-05T09:16:48.880Z",
  "executiveSummary": "The Post Grid and Gutenberg Blocks – ComboBlocks WordPress plugin contains a critical Unauthenticated Hook Injection vulnerability within versions 2.2.32 to 2.3.1.\nThe vulnerability resides in the ~/includes/blocks/form-wrap/function.php file, where improper validation allows unauthenticated remote attackers to trigger arbitrary WordPress hooks.\nThis flaw grants attackers the ability to execute unauthorized actions within the WordPress environment, potentially leading to unauthorized data modification, settings manipulation, or escalation of privileges, provided that no additional compensating security controls are implemented on the hooked functions.\nDue to the lack of authentication requirements, the attack vector is exposed to any remote user capable of reaching the WordPress site, making it a high-risk security concern for all affected installations.\nOrganizations using this plugin are advised to prioritize updates or implement immediate monitoring of the affected file paths for suspicious callback triggers.",
  "technicalDetails": "The vulnerability is classified as an Unauthenticated Hook Injection, stemming from insufficient input sanitization and a lack of access control checks within the plugin's architectural design.\nThe primary area of concern is the ~/includes/blocks/form-wrap/function.php file, which exposes internal plugin functions that facilitate the invocation of WordPress hooks.\nIn the affected versions (2.2.32 to 2.3.1), the logic governing these functions fails to verify the authentication status of the request initiator, effectively allowing any unauthenticated actor to interact with the hook-calling mechanism.\nThe attack flow initiates when an attacker crafts a malicious request targeting the entry point defined in the vulnerable file. Since the code does not enforce nonces or permission checks, the WordPress application proceeds to execute the requested hook callback.\nBy manipulating the request parameters, an attacker can influence which hooks are fired. If the plugin's functions are designed to interact with sensitive WordPress APIs or administrative functions, an attacker can leverage this injection to bypass intended operational flow.\nThe severity of this vulnerability is amplified because it does not require a valid session or elevated privileges; it operates at the public-facing layer of the plugin. The post-exploitation impact is highly dependent on the hooks available within the specific WordPress installation. An attacker could potentially trigger actions that modify plugin settings, alter form configurations, or exploit secondary vulnerabilities in other components by chaining these hook executions.\nEssentially, the vulnerability treats user-supplied input as a trusted trigger for internal application logic. The absence of strict input filtering allows for the execution of arbitrary actions that were intended to be restricted to administrative users. This architectural oversight in ~/includes/blocks/form-wrap/function.php bypasses standard security models provided by the WordPress core for managing hook execution security.\nSuccessful exploitation requires the attacker to identify the specific input parameters that map to the exposed hook calls, which can typically be performed via standard traffic analysis of the plugin's front-end interactions."
}