Analysis Report · Folder Analysis cache/front-editor_5.0.0 → cache/front-editor_5.0.1 — CVE-2025-13419

I'll analyze this code diff for security vulnerabilities.

Vulnerability Existed: yes
TRUE POSITIVE
Insecure Direct Object Reference (IDOR) / Broken Object Level Authorization - CWE-639 - inc/fields/FileField.php lines 100-127 (old code)

Old Code:
```php
public static function revert_file( \WP_REST_Request $request ) {
    $attachment_id = intval( $request->get_body() );
    if ( !empty( $attachment_id ) && $attachment_id ) {
        $deleted = wp_delete_attachment( $attachment_id, true );
    }
}
```

Fixed Code:
```php
public static function revert_file( \WP_REST_Request $request ) {
    self::start_session_if_needed();
    $attachment_id = intval( $request->get_body() );
    if ( empty( $attachment_id ) ) {
        return new \WP_Error('invalid_id', __( 'Invalid attachment ID.', 'front-editor' ), [
            'status' => 400,
        ]);
    }
    $authorized = false;
    $is_guest_upload = false;
    if ( is_user_logged_in() ) {
        if ( current_user_can( 'delete_post', $attachment_id ) ) {
            $authorized = true;
        }
    }
    if ( !$authorized && !empty( $_SESSION['bfe_uploaded_files'] ) && in_array( $attachment_id, $_SESSION['bfe_uploaded_files'] ) ) {
        $authorized = true;
        $is_guest_upload = true;
    }
    if ( !$authorized ) {
        return new \WP_Error('rest_forbidden', __( 'Sorry, you are not allowed to delete this attachment.', 'front-editor' ), [
            'status' => 403,
        ]);
    }
    $deleted = wp_delete_attachment( $attachment_id, true );
    if ( $deleted && $is_guest_upload ) {
        $index = array_search( $attachment_id, $_SESSION['bfe_uploaded_files'] );
        if ( $index !== false ) {
            unset($_SESSION['bfe_uploaded_files'][$index]);
        }
    }
}
```

Explanation:
The original code allowed any authenticated or unauthenticated user to delete any attachment by simply providing an attachment ID, with no authorization checks. The fix implements proper authorization by:
1. Checking if the logged-in user has permission to delete the post via `current_user_can('delete_post', $attachment_id)`
2. For guest users, restricting deletion to only files they uploaded (tracked in `$_SESSION['bfe_uploaded_files']`)
3. Returning a 403 Forbidden error if the user is not authorized
4. Cleaning up the session tracking after successful deletion

---

Vulnerability Existed: not sure
Session Fixation / Insecure Session Handling - CWE-384 - inc/fields/FileField.php lines 135-139

Old Code:
Not present (new code)

Fixed Code:
```php
private static function start_session_if_needed() {
    if ( session_status() === PHP_SESSION_NONE ) {
        session_start();
    }
}
```

Explanation:
The code initializes PHP sessions without regenerating the session ID. While this implementation prevents multiple `session_start()` calls, it does not call `session_regenerate_id()` after starting the session, which could allow session fixation attacks in certain scenarios. However, this depends on whether sessions are already being regenerated elsewhere in the WordPress application (WordPress typically handles this). The implementation is reasonable for a minimal fix, but could be strengthened by adding `session_regenerate_id(true)` if sessions weren't previously regenerated.