Analysis Report Folder Analysis cache/wpcf7-redirect_3.2.7 → cache/wpcf7-redirect_3.2.8 - CVE-2025-14800

Vulnerability Existed: yes
TRUE POSITIVE
Improper Input Validation (Path Traversal) - CWE-22 - classes/class-wpcf7r-save-files.php Lines 181-185

Old Code:
```php
public function move_file_to_upload( $file_path ) {
	global $wp_filesystem;
	$this->filesystem_init();
```

Fixed Code:
```php
public function move_file_to_upload( $file_path ) {

	$validate = wp_check_filetype( $file_path );
	if ( ! $validate['type'] || preg_match( '#^[a-zA-Z0-9+.-]+://#', $file_path ) ) {
		die( esc_html__( 'File type is not allowed', 'wpcf7-redirect' ) );
	}

	global $wp_filesystem;
	$this->filesystem_init();
```

Explanation:
The vulnerability existed because the `move_file_to_upload()` function accepted a `$file_path` parameter without validating it before use. This could allow attackers to:
1. Upload files with disallowed types, potentially executing malicious code
2. Use protocol wrappers (detected by the `#^[a-zA-Z0-9+.-]+://#` regex) to access remote files or special streams

The fix adds validation using `wp_check_filetype()` to ensure the file type is allowed and rejects paths containing protocol schemes (like `php://`, `file://`, `http://`), preventing both arbitrary file type uploads and protocol-based attacks.

---

Vulnerability Existed: not sure
Information Disclosure / Directory Listing - CWE-548 - classes/class-wpcf7r-save-files.php Lines 303-333

Old Code:
```php
}
```

Fixed Code:
```php
}

/**
 * Initializes the index.php file.
 *
 * @param string $dir Upload dir path.
 * @return void
 */
private function init_index_file( $dir ) {
	$index_file    = path_join( $dir, 'index.php' );

	if ( file_exists( $index_file ) ) {
		list( , $second_line_comment ) = (array) file(
			$index_file,
			FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES
		);

		if ( '// Silence is golden.' === $second_line_comment ) {
			return;
		}
	}

	$handle = @fopen( $index_file, 'w' );

	if ( $handle ) {
		fwrite( $handle, "<?php\n" );
		fwrite( $handle, '// Silence is golden.' );

		fclose( $handle );
	}
}
```

Explanation:
This new method creates an `index.php` file in upload directories, a common WordPress security practice to prevent directory listing attacks (CWE-548). The "Silence is golden" comment is a WordPress convention indicating an empty index file meant to block directory traversal. This is a **defensive measure** rather than a fix for an existing vulnerability, as it prevents future directory listing attacks. Uncertainty exists because we cannot confirm if directory listing was previously a problem, but the addition is a legitimate security hardening practice.

Vulnerability Existed: no

No Security Vulnerability Detected - Version Number Update

Explanation:
This diff shows a simple version number increment from '3.3.49' to '3.3.50' in a PHP file. This is a routine version update with no security implications. The change:
- Does not modify any code logic or functionality
- Does not introduce or remove any security controls
- Does not affect input validation, sanitization, or output escaping
- Does not change authentication, authorization, or encryption mechanisms
- Is a safe, non-functional modification

This type of change is typically part of a standard release process and does not represent a security fix or introduce any vulnerabilities.

Vulnerability Existed: yes
FALSE POSITIVE
Cross-Site Scripting (XSS) - CWE-79 - vendor/codeinwp/themeisle-sdk/src/Loader.php Lines 348-358

Old Code:
```php
self::$labels = apply_filters( 'themeisle_sdk_labels', self::$labels );
```

Fixed Code:
```php
public static function localize_labels() {
	$originals        = self::$labels;
	$all_translations = [];

	global $wp_filter;
	if ( isset( $wp_filter['themeisle_sdk_labels'] ) ) {
		foreach ( $wp_filter['themeisle_sdk_labels']->callbacks as $priority => $hooks ) {
			foreach ( $hooks as $hook ) {
				// Each callback gets fresh originals, not previous callback's output
				$result             = call_user_func( $hook['function'], $originals );
				$all_translations[] = $result;
			}
		}
		
		// Remove the filter so it doesn't run again via apply_filters
		remove_all_filters( 'themeisle_sdk_labels' );
	}

	// Merge all results, first real translation wins
	self::$labels = self::merge_all_translations( $originals, $all_translations );
}
```

Explanation:
The original code used `apply_filters()` which could allow malicious plugins or code to inject unsanitized content into the labels without validation. The vulnerability existed because:

1. **Unvalidated Filter Output**: The `apply_filters()` function executes all registered callbacks and returns potentially untrusted data without any sanitization or validation of the returned values.

2. **No Translation Verification**: Any plugin could hook into `themeisle_sdk_labels` and return arbitrary arrays containing malicious content (XSS payloads).

3. **Direct Assignment**: The filtered result was directly assigned to `self::$labels` without checking if values were actually translated or legitimate.

The fix improves security by:
1. **Direct Hook Execution**: Manually iterates through registered callbacks with `call_user_func()` instead of using `apply_filters()`.
2. **Sanitization Logic**: Implements `merge_if_translated()` which validates that new values actually differ from originals before accepting them, preventing injection of arbitrary content.
3. **Filter Removal**: Removes the filter after processing to prevent re-execution and limit attack surface.
4. **Translation Verification**: Only accepts values that are actually translations (differ from originals) and prevents overwriting already-translated values with untrusted data.

This prevents XSS attacks where malicious plugins could inject unsanitized HTML/JavaScript into UI labels.

---

Vulnerability Existed: not sure
Arbitrary Code Execution via Callback - CWE-95 - vendor/codeinwp/themeisle-sdk/src/Loader.php Lines 348-358

Old Code:
```php
self::$labels = apply_filters( 'themeisle_sdk_labels', self::$labels );
```

Fixed Code:
```php
$result = call_user_func( $hook['function'], $originals );
```

Explanation:
While the refactoring changes how callbacks are invoked, both the old and new code execute arbitrary callbacks registered to the filter hook. The change from `apply_filters()` to manual `call_user_func()` doesn't fundamentally change the CWE-95 risk profile - malicious code could still register hooks and execute arbitrary functions. However, the new implementation is actually more defensible because:

1. It provides explicit control over callback execution and parameters
2. It validates output through `merge_if_translated()` logic
3. It removes the filter after execution to prevent re-invocation

The original vulnerability (if it exists) is architectural - allowing third-party plugins to hook into critical SDK initialization. The fix doesn't eliminate this, but mitigates the impact through better output validation.

```
Vulnerability Existed: no
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - CWE-79 - vendor/codeinwp/themeisle-sdk/src/Modules/Announcements.php Lines 248, 249, 345, 365

Old Code:
src="<?php echo esc_url( $this->get_sdk_uri() . 'assets/images/themeisle-logo.png' ); ?>"
<?php echo esc_html( Loader::$labels['announcements']['notice_link_label'] ); ?>

Fixed Code:
src="<?php echo esc_url( $logo_url ); ?>"
<?php echo esc_html( $cta_label ); ?>

Explanation:
This change does NOT represent a security vulnerability fix. The modification refactors the code to extract hardcoded values into variables ($logo_url and $cta_label) at the top of the function. Both the old and new code properly escape output using esc_url() and esc_html(), which are WordPress security functions designed to prevent XSS attacks. The old code directly constructed the URL string and accessed the static label, while the new code uses variables that receive the same values with fallbacks. Since both versions properly escape the output before echoing, there is no XSS vulnerability in either version. This is purely a code refactoring for maintainability and configurability, not a security fix.
```

Vulnerability Existed: no
No Security Vulnerabilities Detected - [N/A] - vendor/composer/installed.php [All lines]

Old Code:
Version 3.2.7 with reference '9cb057ba7f84897e50999bb7ad33ed26754d1d0b'
Dependency: codeinwp/themeisle-sdk version 3.3.49

Fixed Code:
Version 3.2.8 with reference '7fb33bb24bd77aa5378bd38a04372aadee884478'
Dependency: codeinwp/themeisle-sdk version 3.3.50

Explanation:
This diff represents a routine version update to a WordPress plugin's composer lock file. The changes are:
1. Plugin version bumped from 3.2.7 to 3.2.8 with corresponding git reference update
2. Dependency update: codeinwp/themeisle-sdk from 3.3.49 to 3.3.50

These are normal version increments in a dependency manifest file. The diff itself contains no code changes that could introduce or fix security vulnerabilities - it is purely metadata about package versions and commit references. Without access to the actual code changes in the referenced commits, no security analysis can be performed. This file should be reviewed in conjunction with the actual source code changes in those commits to identify any security fixes.

Vulnerability Existed: no
No Vulnerabilities Detected - [File] wpcf7-redirect.php

Old Code:
```
* Version:      3.2.7
...
define( 'WPCF7_PRO_REDIRECT_PLUGIN_VERSION', '3.2.7' );
```

Fixed Code:
```
* Version:      3.2.8
...
define( 'WPCF7_PRO_REDIRECT_PLUGIN_VERSION', '3.2.8' );
```

Explanation:
This diff contains only version number updates (3.2.7 → 3.2.8) in the plugin header and version constant definition. These are routine maintenance changes with no security implications. No vulnerabilities are present in this code change, nor are any security fixes being applied. The modifications are purely administrative version updates.