Recherche « Gravity Forms »

geekontheroad Live Summary for Gravity Forms

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in geekontheroad Live Summary for Gravity Forms live-summary-for-gravity-forms allows Reflected XSS.This issue affects Live Summary for Gravity Forms: from n/a through 1.2.10.

Rocketgenius, Inc Gravity Forms

Deserialization of Untrusted Data vulnerability in Rocketgenius, Inc Gravity Forms gravityforms allows Object Injection.This issue affects Gravity Forms: from n/a before 3.1.1.

Unknown click5 CRM add-on to Gravity Forms

The click5 CRM add-on to Gravity Forms WordPress plugin through 1.0.3 does not sanitise and escape content submitted through an unauthenticated endpoint before outputting it back in an admin page, leading to Stored XSS which could be used against high privilege users such as admin.

GravityKit GravityExport Lite for Gravity Forms

Unauthenticated Broken Access Control in GravityExport Lite for Gravity Forms <= 2.7.2 versions.

knitpay Knit Pay – Cashfree, Instamojo, Razorpay, PayPal and more

The Knit Pay – Cashfree, Instamojo, Razorpay, PayPal and more plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 9.6.1.0. This is due to the `maybe_update_user_role()` function reading the target role directly from an attacker-controlled Gravity Forms entry field — configured via the feed's `user_role_field_id` — and passing it to `WP_User::set_role()` without validating the supplied value against an allowlist of permitted roles. This makes it possible for authenticated attackers, with Subscriber-level access and above, to elevate their privileges to administrator by tampering with the hidden role field value at form submission time. Exploitation is further enabled by the fact that $0 orders are synchronously marked as SUCCESS during form submission without requiring a real payment, and when no GF User Registration user can be resolved, the role assignment target falls back to `$lead['created_by']` — the currently authenticated submitter's own user ID — making any authenticated form submitter an eligible exploitation target.

addonsorg Repeater Fields for Gravity Forms

The Repeater Fields for Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Repeated Multi-Input Sub-Field Values in all versions up to, and including, 3.0.4 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This vulnerability only affects multi-input sub-field types within a repeater (such as Name, Address, and Checkbox fields), as scalar single-input field values are escaped with esc_html() at the output stage in version 3.0.4.

Gravity Forms

The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Post Body Field Value in all versions up to, and including, 2.10.5 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The exploit survives save-time sanitization because wp_kses_post allows the required HTML tags and attributes, and the client-side tooltip script re-parses the browser-decoded aria-label value as innerHTML while only stripping script elements, leaving onerror and other event-handler attributes fully intact and executable.

Gravity Forms

The Gravity Forms plugin for WordPress is vulnerable to Arbitrary File Upload in all versions up to, and including, 3.0.2. This is due to insufficient validation of multi-file upload chunk state in the `GFAsyncUpload::upload()` function, where public form state URL hashes can be reused as chunk continuation hashes and attacker-controlled temporary filenames are accepted before sanitization. This makes it possible for unauthenticated attackers, when a public form contains a File Upload field with Multiple Files enabled, to upload a valid PNG/PDF polyglot to an attacker-selected public `.php` or `.html` filename in the Gravity Forms temporary upload directory. This can lead to remote code execution on WordPress systems that use NGINX or other non `.htaccess` respecting web servers. NOTE: During installation and activation, the Gravity Forms plugin places a `.htaccess` file in this directory, which prevents this vulnerability from being exploited despite the PHP file being written to the temporary upload directory. In these cases where PHP execution is blocked, attacker-written HTML can result in stored same-origin cross-site scripting if a victim visits the generated file URL.

WPExperts Gravity Forms Bookings premium

Subscriber SQL Injection in Gravity Forms Bookings premium <= 2.1 versions.

Pronamic Pay

The Pronamic Pay plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 10.1.0 This is due to the `maybe_update_user_role()` function passing an attacker-controlled Gravity Forms field value (`$lead[$feed->user_role_field_id]`) directly into `WP_User::set_role()` without any allowlist validation, capability comparison, or permission check to constrain which roles can be assigned. This makes it possible for authenticated attackers, with Subscriber-level access and above, to escalate their own WordPress account to Administrator by tampering with the role field value in a form submission. Exploitation requires that an administrator has already configured a Pronamic Pay payment feed in Gravity Forms with the **Update User Role** option enabled and mapped to a form field; once that configuration is in place, no further preconditions exist to prevent an authenticated attacker from exploiting this vulnerability.

Gravity Forms

The Gravity Forms plugin for WordPress is vulnerable to Directory Traversal in all versions up to, and including, 2.10.4 via the 'gform_uploaded_files' parameter parameter. This makes it possible for unauthenticated attackers to read the contents of arbitrary files on the server, which can contain sensitive information. Exploitation requires the targeted form to not enforce login (so publicly accessible), which allows the unauthenticated attacker to reach the process_send_resume_link endpoint and supply an arbitrary recipient email address to receive the traversal-retrieved file as a notification attachment.

Hannan گرویتی فرم فارسی

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Hannan گرویتی فرم فارسی persian-gravity-forms allows Blind SQL Injection.This issue affects گرویتی فرم فارسی: from n/a through <= 3.0.2.

plugcrux Integration for Freshsales – Contact Form 7, WPForms, Elementor, Gravity Forms and More

The Integration for Freshsales – Contact Form 7, WPForms, Elementor, Gravity Forms and More plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Form Submission Data in all versions up to, and including, 1.0.15 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The injected payload only executes when a CRM API call fails for the submitted form and an administrator subsequently views the error log details modal in the WordPress admin panel.

Gravity Forms

The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Consent field hidden inputs in versions up to and including 2.10.0. This is due to a flawed state validation mechanism that fails open when input is sanitized by wp_kses(), combined with insufficient output escaping. The state validation logic creates two hashes (raw input and wp_kses-sanitized input) and only fails validation if BOTH hashes don't match the original state. When an attacker injects XSS payloads using tags stripped by wp_kses() (like <svg>), the sanitized hash matches while the malicious raw value is preserved and saved to the database. When administrators view the Entries List page, the stored malicious consent label is retrieved and output without escaping, causing the XSS payload to execute. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in entries that will execute whenever an authenticated administrator accesses the entries list page.

Gravity Forms

The Gravity Forms plugin for WordPress is vulnerable to Unauthenticated Stored Cross-Site Scripting in versions up to and including 2.10.0. This is due to insufficient input validation and output escaping of Calculation Product field product names when rendered inside Repeater fields. The validate() method in the GF_Field_Calculation class only validates the quantity field (.3) and completely ignores the product name field (.1), allowing malicious HTML to pass through validation. When the value is saved, the sanitize_entry_value() method returns the raw value without sanitization for fields where HTML is not expected. Subsequently, when an entry is viewed in wp-admin, the get_value_entry_detail() method concatenates the unescaped product name directly into the output string, which is then rendered by the repeater's get_value_entry_detail() method without further escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts via form submissions that will execute whenever an authenticated administrator with the gravityforms_view_entries capability accesses the entry detail page.

Gravity Forms

The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting in versions up to and including 2.10.0. This is due to insufficient input validation and output escaping on Hidden Product field values when used inside Repeater fields, where repeater subfields bypass state validation checks and the Hidden Product validate() method only validates the quantity field while ignoring the product name field that is later output without proper escaping in the get_value_entry_detail() method. This makes it possible for unauthenticated attackers to inject arbitrary web scripts through form submissions that will execute whenever an administrator views the entry details.

Gravity Forms

The Gravity Forms plugin for WordPress is vulnerable to Unauthenticated Stored Cross-Site Scripting in versions up to and including 2.10.0. This is due to insufficient input validation and output escaping in the SingleProduct field when used inside a Repeater field. When SingleProduct fields are nested within Repeater fields, the validation flow bypasses the state validation mechanism (failed_state_validation()) that would normally prevent tampering with field values. The validate_subfield() method only calls the field's validate() method, which for SingleProduct fields only validates the quantity field and does not check the product name field for tampering. As a result, an attacker can inject arbitrary HTML and JavaScript into the product name field (input .1). This malicious input is then saved to the database without sanitization because sanitize_entry_value() returns raw values when HTML is not expected for the field type. When an administrator views the entry in wp-admin/admin.php?page=gf_entries, the get_value_entry_detail() method outputs the product name without escaping, causing the stored XSS payload to execute in the administrator's browser. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever an administrator accesses an entry containing the malicious payload.

Gravity Forms

The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting in versions up to and including 2.10.0. This is due to insufficient validation and output escaping of Product Option field values. The vulnerability exists because the state validation function accepts submitted values where the wp_kses()-sanitized version matches a legitimate option value, but then stores the raw unsanitized value in the database. When administrators view entry details via the Order Summary section, the option_label is output directly without escaping (view-order-summary.php line 32), executing the injected JavaScript. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in entry data that will execute whenever an administrator accesses the entry details page.