MCP Servers Pose Serious Security Risks as Attackers Exploit Permanent Trust Model

·3 views

Model Context Protocol (MCP) servers, used to extend AI coding agents with tools and data access, contain critical security vulnerabilities that researchers say are largely unaudited. Once approved, an MCP server retains permanent access to a user's tools, prompts, and data with no re-authentication required. A demonstrated attack chain shows malicious servers behaving normally for the first few interactions before triggering payloads that exfiltrate SSH keys, cloud credentials, and shell history — succeeding roughly 90% of the time in tests against a leading coding agent. A separate technique dubbed 'GhostJacking' embeds hidden instructions inside blocked firewall requests, causing AI agents to unknowingly rewrite DNS settings while reporting the issue as resolved. Security experts recommend treating every MCP server as a privileged access point, keeping DNS and config changes behind human approval, and regularly rotating credentials for any long-running MCP configurations.

Read the full story at DEV Community

This is an AI-generated summary. ShortSingh links to the original source for the complete article.

Discussion (0)

Drupal Web Development in 2026: What Organisations Need to Know

Drupal is a free, open-source CMS that has been in active development for over two decades, now on its 11th major version built on modern PHP and the Symfony framework. It is widely trusted by governments, universities, and large enterprises for projects requiring structured content, complex permissions, and robust security. Unlike WordPress, which prioritises ease of use and suits most small-to-medium sites, Drupal offers greater flexibility and power but comes with a steeper learning curve. Its strengths include fine-grained user roles, strong multilingual support, and the ability to scale without requiring a site rebuild. Organisations are advised to choose Drupal when their project demands complex content modelling and high security, and to consider simpler tools for more straightforward requirements.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Why 3D product configurators must calculate prices server-side, not client-side

Client-side price calculation in Three.js product configurators is a critical security flaw, as any user can manipulate the price variable via browser DevTools and submit fraudulent orders. The correct approach separates responsibilities: the frontend displays only a clearly labeled price estimate for a smooth user experience, while the backend independently recalculates the authoritative price at order submission. A recommended 'Confirm order' step fetches the real server-side price before final checkout, eliminating any discrepancy between the preview and the actual charge. The same principle extends to configuration validation, where shared JSON Schema rules provide real-time frontend feedback but the backend serves as the final enforcement gate. This pattern is already used by platforms like Shopify custom apps, Bagisto, and Zakeke to prevent pricing manipulation.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Developer Releases Dockerized Vulnerable PHP/MySQL Lab for Web Security Practice

A developer has built and open-sourced a deliberately vulnerable PHP/MySQL application designed for practicing web and API security in a local environment. Unlike typical CTF challenges, the vulnerabilities are modeled on real-world patterns the creator encountered during personal security research. The Dockerized lab includes 10 intentional flaws such as BOLA, JWT forgery, unrestricted file upload leading to remote code execution, and time-based SQL injection. Field manuals are included in the repository to guide users through intended exploit chains if needed. The project is available on GitHub, with a strong caution to run it only in isolated, offline environments and never against unauthorized systems.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Developer reveals six data leak paths that bypassed correct Supabase RLS policies

A developer building a multi-tenant point-of-sale system on Supabase and Postgres discovered six distinct data leakage vulnerabilities over three security reviews spanning six weeks. Each leak slipped past Row Level Security policies that were technically correct as written, exposing gaps in the seams between Postgres privileges, RLS, and the PostgREST API layer. Key issues included default EXECUTE grants to PUBLIC on functions, column-level privilege asymmetries where new columns were writable but not readable by default, and SECURITY DEFINER views that unintentionally exposed write operations through PostgREST. One flaw silently allowed a browser client to reset an invoice counter, which could have produced duplicate entries in a tax invoice book. The developer shared specific fixes for each vulnerability, emphasizing that RLS alone is insufficient and that every new database object and column requires explicit privilege review for both reads and writes.

0 comments Read more at DEV Community