10 posts tagged with "Security"

Google just handed independent publishers a way to fight back against AI scraping with their "Preferred Sources" tool, while hackers are simultaneously punishing anyone who ignores their composer.lock with a massive new malware campaign.

Why I'm Watching This​

If you run a WordPress site in 2026, you're fighting a two-front war: visibility and integrity.

1. Visibility: AI Overviews often bury the original source. If you break a story or write the definitive guide, you want Google to know you are the primary source, not the AI summarizer.
2. Integrity: The "Widespread WordPress Malware Campaign" reported this week isn't sophisticated—it's just opportunistic. It targets the lazy.

I've been spending time this weekend auditing my sites against these two updates.

The Analysis​

Google's "Preferred Sources"​

According to the latest reports, this tool allows publishers to explicitly signal "original reporting" via structured data or Search Console configuration. It's effectively a canonical tag for facts.

Here is how the flow changes for content producers:

If you are a technical writer or news breaker, ignoring this means you are voluntarily feeding the model without getting the traffic credit.

The Malware Wave​

The report from Squared Tech highlights that this campaign specifically targets "outdated plugins." This isn't a zero-day exploit in core; it's an exploit of the "set it and forget it" mentality.

The most dangerous thing you can do right now is rely on auto-updates that might fail silently. You need active scanning.

# Don't just update; audit first.
# Check for known vulnerabilities in your lock file.
composer audit

# If clean, then update safely
composer update --with-dependencies

Dashboard -> Updates -> "Update All"

# Why this fails:
# 1. No audit trail.
# 2. PHP timeouts can leave sites in maintenance mode.
# 3. Doesn't check against vulnerability databases (usually).

The Code​

No separate repo—this is an operational update based on industry reports.

I am currently updating my drupal-eu-sovereignty-checklist (which applies to WP as well) to include a check for these "Preferred Source" meta tags, as I suspect this will become a compliance standard for EU publishers wanting to protect their IP rights.

What I Learned​

• SEO is now "Source Authority": Keywords matter less than proving provenance. If Google offers a tool to claim authorship, use it immediately.
• "Preferred Sources" needs Schema: While the UI exists, likely the heavy lifting is done via JSON-LD. I'm digging into the specs to see if NewsArticle schema needs a specific property for this.
• Composer Audit is non-negotiable: The malware campaign targeting "outdated plugins" is easily thwarted by running composer audit in your CI/CD pipeline. If you aren't blocking deployments on high-severity CVEs, you're asking for trouble.
• Old plugins are liabilities: If a plugin hasn't been updated in 6 months, replace it. The attack surface is too high.

References​

• Google's 'Preferred Sources' Tool: A New SEO Frontier for WordPress Publishers
• Widespread WordPress Malware Campaign Targets Outdated Plugins

Inspired by Dries Buytaert's recent insights on AI-Driven Vulnerability Discovery, I built a tool to address one of the biggest challenges in modern open-source security: Triage at Machine Speed.

As AI makes it easier and cheaper to find potential vulnerabilities, open-source maintainers are facing an unprecedented flood of security reports. The bottleneck is no longer finding bugs, but evaluating and triaging them without burning out the human maintainers.

The recent security alert regarding Moltbook, an AI-only social platform, serves as a stark reminder that "vibe coding" — while incredibly productive — can lead to catastrophic security oversights if fundamental principles are ignored.

The Moltbook Exposure​

In early February 2026, cybersecurity firm Wiz identified critical flaws in Moltbook. The platform, which was built primarily using AI-assisted coding, suffered from basic misconfigurations that led to:

• Exposure of 1.5 million AI agent API authentication tokens.
• Leak of plaintext OpenAI API keys found in private messages between agents.
• Publicly accessible databases without any authentication.

The creator admitted that much of the platform was "vibe coded" with AI, which likely contributed to the oversight of standard security measures like authentication layers and secret management.

The Lesson: Vibe with Caution​

AI is great at generating code that works, but it doesn't always generate code that is secure by default unless explicitly instructed and audited. When building AI integrations, especially in platforms like Drupal, it's easy to accidentally store API keys in configuration or expose environment files.

Introducing: AI Security Vibe Check for Drupal​

To help the Drupal community avoid similar pitfalls, I've built a small utility module: AI Security Vibe Check.

This module provides a Drush command and a service to audit your Drupal site for AI-related security risks:

• Config Scan: Automatically detects plaintext OpenAI, Anthropic, and Gemini API keys stored in your Drupal configuration (which could otherwise be exported to YAML and committed to Git).
• Public File Audit: Checks for exposed .env or .git directories in your web root.
• Drush Integration: Easily run drush ai:vibe-check to get a quick health report on your AI security "vibe."

View Code

View Code on GitHub

Building with AI is the future, but let's make sure our "vibes" include a healthy dose of security auditing.

Issue: Moltbook Security Alert

In early 2026, the WordPress ecosystem was rocked by a widespread security breach that infected over 40,000 sites. The culprit? A critical administrative bypass vulnerability in the Modular DS Connector plugin, tracked as CVE-2026-23550.

The Vulnerability: CVE-2026-23550​

The vulnerability is a classic example of a flawed authentication check. The plugin's isDirectRequest() method, intended to validate requests from the central Modular DS dashboard, could be tricked by simply adding origin=mo to the URL parameters.

This allowed unauthenticated attackers to target the /api/modular-connector/login/ endpoint and gain full administrative access to the site.

Key Facts:​

• Severity: 10/10 (Critical)
• Impact: Complete site takeover
• Active Exploitation: Detected starting January 13, 2026
• Affected Version: 2.5.1 and earlier
• Fixed Version: 2.5.2

The Impact​

Because Modular DS is a multi-site management tool, the breach was particularly devastating. Attackers could potentially leverage access to a central dashboard to compromise all connected WordPress installations.

Common indicators of compromise (IoCs) include:

• Unexpected administrative accounts created.
• Malicious scripts injected into theme files.
• Redirects to phishing pages or fraudulent content.

Defensive Measures​

1. Update Immediately: Ensure the Modular DS Connector plugin is updated to at least version 2.5.2.
2. Regenerate Salts: If you were running a vulnerable version, it is highly recommended to regenerate your WordPress salts.
3. Audit Admin Users: Review all administrator accounts and remove any that are unrecognized.
4. Scan for Malware: Use a reputable security plugin to scan your files and database for malicious code.

Vulnerability Checker​

I have built a simple Python-based tool to check if a WordPress site is still vulnerable to this specific bypass.

View Code

View Code on GitHub

# Quick check example
python checker.py https://your-wordpress-site.com

This tool performs a non-intrusive check on the specific endpoint using the known bypass parameters to identify if the vulnerability is present.

Stay safe and keep your plugins updated!

In February 2026, a widespread malware campaign targeted thousands of WordPress sites, exploiting vulnerabilities in outdated plugins. One significant flaw was CVE-2025-67987, a critical SQL injection vulnerability in the popular "Quiz And Survey Master" (QSM) plugin.

To help developers and site owners identify these threats, I've built WP Malware Sentinel, a lightweight CLI tool that scans WordPress installations for known malware signatures and audits installed plugins for specific high-risk vulnerabilities.

Key Features​

• Signature Scanning: Detects common malware patterns like obfuscated eval(base64_decode()), suspicious shell executions, and embedded malicious iframes.
• Vulnerability Auditing: Specifically checks for vulnerable versions of plugins involved in current active campaigns (e.g., QSM versions prior to 10.3.2).
• Fast and Extensible: Built with Symfony Components (Finder, Console) for high performance and easy integration into CI/CD or agent workflows.

How it Works​

The scanner traverses the file system looking for signatures defined in its internal database. It also parses readme.txt files of installed plugins to verify stable versions against known vulnerable releases.

# Run a scan on the current directory
./bin/wp-sentinel scan .

Technical Implementation​

The project is written in PHP 8.4 and utilizes PSR-4 autoloading. It includes a comprehensive test suite using PHPUnit to ensure reliable detection without false positives in common WordPress codebases.

View Code

View Code

In a recent insightful post, Dries Buytaert, the founder of Drupal, addressed a growing concern in the open source community: the deluge of AI-generated contributions. While AI can lower the barrier to entry, it often produces low-value reports or patches that lack expertise, overwhelming maintainers who are already stretched thin.

Dries' core message is clear: We need AI tools that empower maintainers, not just contributors.

Inspired by this, I've developed a prototype called Drupal Maintainer Shield.

The Problem: Maintainer Fatigue​

The "curl" project recently had to end its bug bounty program due to a flood of AI-generated security reports that were mostly noise. This is "maintainer fatigue" in action. If every AI agent can spin up a patch in seconds, the human bottleneck—the reviewer—becomes the point of failure for the entire ecosystem.

The Solution: Signal vs. Noise Filtering​

Drupal Maintainer Shield is a CLI tool designed to act as a first line of defense for Drupal maintainers. It uses AI-driven heuristics to analyze incoming patches and issue descriptions, scoring them based on "Signal" vs. "Noise".

View Code View Code

How it Works​

The tool looks for two categories of signals:

1. Quality Signals: Use of structured security metadata (e.g., Security-Category), specific CVE references, and high-signal code patterns (like fixing unsanitized db_query calls).
2. Noise Signals: Generic AI boilerplate (e.g., "As an AI language model...") or vague descriptions typical of automated scanner exports.

Example Analysis​

When a maintainer runs the shield against a high-quality security patch:

bin/shield analyze patch.txt

They get a clear recommendation:

Recommendation: HIGH SIGNAL - PRIORITIZE Confidence Score: 100/100 Findings: References specific CVE ID, Potential SQL injection fix detected.

Conversely, a low-effort report might be flagged as:

Recommendation: PROBABLE NOISE - LOW PRIORITY Warning: This contribution matches common AI noise patterns. Proceed with caution.

Toward Responsible AI​

As we move toward a world where AI agents are primary contributors to codebases, we must build the infrastructure to verify and validate their work. Tools like Drupal Maintainer Shield are small steps toward a future where AI helps us scale security without burning out the humans who make open source possible.

Check out the project on GitHub and let's discuss how we can improve AI tools for maintainers.

View Code

The PHP world doesn't sleep. Today brought a critical wave of security patches across the entire Symfony ecosystem (from 5.4 LTS to 8.0) and a forward-looking release from Pantheon's Terminus CLI adding support for the upcoming PHP 8.5.

Why I'm Flagging This​

Dependency management is often "set and forget" until a CVE hits. The sheer breadth of today's Symfony security release—touching five major branches—is a reminder that even stable, mature frameworks have surface area that needs constant watching.

Simultaneously, seeing platform tools like Terminus prep for PHP 8.5 (while many of us are just settling into 8.3/8.4) signals that the infrastructure layer is moving fast. If your tooling lags, your ability to test new features lags.

The Solution: Patching & Upgrading​

Symfony Security Sweep​

The Symfony team released versions 8.0.5, 7.4.5, 7.3.11, 6.4.33, and 5.4.51. These aren't feature drops; they are security hardenings. If you are running a composer-based project (Laravel, Drupal, native Symfony), you need to verify your lock file isn't pinning a vulnerable version.

# Check for known security vulnerabilities in your dependencies
composer audit

# Update only symfony packages
composer update "symfony/*" --with-dependencies

Terminus & PHP 8.5​

Pantheon's CLI tool, Terminus, bumped to 4.1.4. The headline feature is PHP 8.5 support. While PHP 8.5 is still in early development phases, having CI/CD tools that can handle the runtime is essential for early adopters testing compatibility.

# Check your current Terminus version
terminus --version

# Update Terminus (if installed via phar/installer)
terminus self:update

The Code​

No separate repo—this is a maintenance and infrastructure update cycle.

What I Learned​

• LTS is a commitment: Seeing Symfony 5.4.51 in the release list proves the value of Long Term Support versions. You don't have to be on the bleeding edge to get security patches, but you do have to run the updates.
• Composer Audit is underused: Running composer audit should be part of every CI pipeline. It catches these announcements instantly.
• Tooling leads runtimes: Infrastructure CLIs (like Terminus) often need to support a language version before the application code does, so developers have a stable environment to break things in.

References​

• Pantheon Terminus 4.1.4 Released with PHP 8.5 Support
• Security Release: Symfony 8.0.5, 7.4.5, 7.3.11, 6.4.33, and 5.4.51

The Cloudflare 2025 Q4 DDoS threat report has just been released, and the numbers are staggering. A record-breaking 31.4 Tbps attack was mitigated in November 2025, and hyper-volumetric attacks have grown by 700%.

For Drupal site owners, these aren't just statistics—they represent a fundamental shift in the scale of threats our infrastructure must withstand.

The Aisuru-Kimwolf Botnet Threat​

The report highlights the rise of the Aisuru-Kimwolf botnet, which leverages Android TVs to launch HTTP DDoS attacks exceeding 200 million requests per second (RPS). When an attack of this magnitude hits a CMS like Drupal, even the most optimized database queries can become a bottleneck if the attack bypasses the edge cache.

Key Findings for Infrastructure​

• Short, Intense Bursts: Many record attacks lasted less than a minute but were intense enough to knock unprotected systems offline instantly.
• Cache-Busting Tactics: Attackers are increasingly using sophisticated patterns to bypass CDN caching, forcing the application server to process every request.
• Industry Targeting: Telecommunications and service providers are top targets, but any high-profile site is at risk.

Introducing: Drupal DDoS Resilience Toolkit​

To help Drupal communities implement defense-in-depth, I've built the DDoS Resilience Toolkit. This module provides application-level safeguards that complement edge protection like Cloudflare.

View Code

Features:​

1. Cloudflare Integrity Enforcement: Ensuring your origin ONLY talks to Cloudflare, preventing attackers from bypassing your WAF by hitting your IP directly.
2. Adaptive Rate Limiting: A lightweight, cache-backed mechanism to throttle suspicious IP addresses before they exhaust PHP workers.
3. Pattern-Based Blocking: Detecting "cache-buster" query strings that deviate from normal site usage.

Conclusion​

As we move into 2026, the scale of DDoS attacks will only increase. Relying solely on default configurations is no longer enough. By combining edge mitigation with application-level resilience, we can ensure our Drupal sites remain performant even under extreme pressure.

Ref: Cloudflare 2025 Q4 DDoS Threat Report.

Recently, a critical authenticated SQL injection vulnerability (CVE-2025-9318) was discovered in the Quiz and Survey Master (QSM) WordPress plugin, affecting versions up to 10.3.1. This flaw allowed attackers with at least subscriber-level permissions to execute arbitrary SQL queries via the is_linking parameter.

In this post, we audit the vulnerability, demonstrate how it worked, and show the implementation of the fix.

The Vulnerability: CVE-2025-9318​

The core of the issue was a classic SQL injection pattern: user-supplied input was directly concatenated into a SQL string without being sanitized or passed through a prepared statement.

Vulnerable Code Pattern​

The vulnerable code looked something like this (simplified for demonstration):

function qsm_request_handler($is_linking) {
    global $wpdb;
    
    // VULNERABLE: Direct concatenation of user input into SQL
    $query = "SELECT * FROM wp_qsm_sections WHERE is_linking = " . $is_linking;
    
    return $wpdb->get_results($query);
}

By providing a payload like 1 OR 1=1, an attacker could change the logic of the query to return all sections or extract data using UNION SELECT statements.

The Fix: Prepared Statements​

The vulnerability was resolved in version 10.3.2 by properly utilizing WordPress's $wpdb->prepare() method. This ensures that parameters are correctly typed and escaped before being merged into the query.

Fixed Code Pattern​

function qsm_request_handler($is_linking) {
    global $wpdb;
    
    // FIXED: Using wpdb::prepare to safely handle the parameter
    $query = $wpdb->prepare(
        "SELECT * FROM wp_qsm_sections WHERE is_linking = %d",
        $is_linking
    );
    
    return $wpdb->get_results($query);
}

In the fixed version, the %d placeholder tells WordPress to treat the input as an integer. Any non-numeric payload (like 1 OR 1=1) will be cast to an integer (resulting in 1 in this case), neutralizing the injection attempt.

Audit and Verification​

We have created a standalone audit project that simulates this environment and provides automated tests to verify both the vulnerability and the fix.

View Code View the Audit Repository on GitHub

Key Takeaways​

1. Never Trust User Input: Even parameters that seem "safe" or internal should be treated as malicious.
2. Use Prepared Statements: This is the primary defense against SQL injection in WordPress development.
3. Type Casting: For numeric parameters, casting to (int) provides an extra layer of defense.

Stay secure!

Moltbook is a fast-moving AI-agent social network experiment, but recent reporting highlights serious security exposure risks. Based on those reports, I am not participating right now.