Is Playwright Secure? Vulnerabilities, MCP Risks, and a Secure Alternative (2026)

Liviu Lupei

Founder & Solutions Architect, Endtest · November 3, 2026

Every documented Playwright vulnerability, a real company incident, the risks of Playwright MCP, a security checklist, and how a managed platform changes who owns the security work.

By Liviu Lupei, Founder & Solutions Architect at Endtest
Published November 3, 2026 · Last updated November 3, 2026

Key takeaways

• Playwright is not malicious or backdoored, and it can be used securely. But it is a self-managed framework, so patching, browser updates, sandboxing, and access control are your responsibility.
• Two Playwright-related CVEs are public and patched: CVE-2025-59288 (unverified browser installer downloads, fixed in Playwright 1.55.1) and CVE-2025-9611 (DNS rebinding in Playwright MCP, fixed in @playwright/mcp 0.0.40).
• A real company had an incident. PostHog reported that a researcher exploited an outdated, unsandboxed Chromium running through Playwright and reached credentials inside a Kubernetes pod. The cause was configuration and patching, not a flaw in Playwright's test API.
• Playwright MCP widens the attack surface because an AI agent, a browser, and other privileged tools now share one environment.
• The alternative isn't "unsafe open source vs. safe vendor." It's who operates the browsers, hosts, patches, and monitoring. Endtest is a managed platform with ISO/IEC 27001 certification, so much of that work moves to us.
• Disclosure: I founded Endtest, a commercial alternative to Playwright. The vulnerabilities, incidents, and costs below are documented, and every source is linked so you can check them yourself.

You can install Playwright with a single command.

Then install Chromium. Add Playwright MCP. Connect it to Claude or Cursor. Give your AI agent access to your repository, your terminal, and perhaps a few other tools.

Ten minutes later, you have an impressive AI-powered testing setup.

There's one question that rarely comes up during those ten minutes: who is responsible for securing all of this?

With a self-managed stack, the answer is you. This article looks at what that actually involves, using the public record.

Is Playwright secure?

Playwright can be used securely, but security isn't something the framework provides on its own. It depends on how you run it.

There is no evidence that Playwright itself is malicious. The documented problems fall into three groups: flaws in specific scripts or components that were patched, browser builds that lag behind security fixes, and configuration choices on the user's side. The last two are operational problems, and they stay with whoever runs the infrastructure.

The next sections cover each one.

What security vulnerabilities has Playwright had?

Both vulnerabilities below have official CVE identifiers, and both have been patched. They were disclosed in October 2025 and January 2026, so they are not new this week. Nobody running a current version is affected by them.

CVE-2025-59288: unverified browser installer downloads

This affected Playwright versions before 1.55.1. Some macOS installation scripts used curl with the -k flag, which turns off certificate verification. Certificate checks are how software confirms it is downloading from the server you meant to contact.

Without them, an attacker in a position to intercept network traffic could potentially swap in a malicious browser installer, which might then run with elevated privileges.

This was a flaw in specific installation scripts, not in ordinary test execution, and exploitation required suitable network conditions. Still, a tool meant to test your application could, under the wrong conditions, install an attacker's executable.

CVE-2025-9611: Playwright MCP and DNS rebinding

Versions of @playwright/mcp before 0.0.40 did not validate the Origin header on incoming connections. Under the conditions described in the advisory, a malicious website could talk to a locally running Playwright MCP server and invoke its tools without the legitimate MCP client authorizing anything. The advisory is rated high severity (CVSS 4.0 score of 7.2 in public databases).

The real-world impact depended on which tools the server exposed and what permissions the process had.

Neither CVE means Playwright is malicious. Both show how a small implementation mistake can cross a security boundary that developers assumed was protected.

Can the browser inside Playwright be out of date?

Yes, and this is the issue most teams overlook.

On October 27, 2026, a developer opened Playwright issue #43664 asking for a browser update. It noted that Playwright 1.64.1 bundled Chromium 156.0.8078.4, older than the patched Chrome releases available at the time. Google had published security updates on October 20, 27, and 29, including fixes for critical vulnerabilities.

The issue was closed after a fix was merged on October 30. As of this writing on November 3, the latest stable Playwright package still reported the older bundled Chromium build.

That doesn't mean every reported Chrome vulnerability is exploitable in every Playwright environment. It does show that updating Playwright and keeping the browser underneath it patched are related tasks, not the same task. A green test result says nothing about whether the browser that ran the test is fully patched.

There's also a setting to check. Playwright's documentation states that the chromiumSandbox option defaults to false. That deserves attention whenever automated browsers visit untrusted websites.

Has a real company been compromised through Playwright?

In June 2026, PostHog published a security advisory about an incident involving Chromium and Playwright.

A security researcher exploited a known vulnerability in an outdated Chromium version that PostHog was running through Playwright to generate heatmaps. The browser was running without a sandbox. The researcher obtained a shell inside a Kubernetes pod and reached credentials stored in its environment variables.

PostHog reported that no customer data was accessed and that it found no evidence of exploitation by anyone other than the researchers. It rotated the exposed credentials and updated its browser infrastructure.

This was not a vulnerability in Playwright's assertion API. It was the combination of an outdated browser, a missing sandbox, and sensitive credentials reachable from the execution environment.

That's the point. You can use a legitimate, well-maintained tool, miss one update, configure one setting wrong, and face a serious incident. The framework doesn't have to be malicious for the consequences to be severe.

Is Playwright MCP a security risk?

Playwright MCP adds an interface between AI agents and browser automation, and its risk depends on four things: the version, the tools it exposes, whether it is reachable over the network, and what permissions its process has.

Traditional test automation already required trust. You installed a framework, gave it access to browsers, and let it interact with applications. With MCP, the same framework is connected to an AI agent.

A typical setup has Claude or Cursor, an MCP server, a browser, and other tools attached to the same agent. That agent may be able to read repository files, run terminal commands, use authenticated websites, or call external services. Playwright MCP doesn't automatically get your whole filesystem or inbox, but the overall agent environment can have very broad reach.

That creates several realistic failure modes:

• A vulnerability in the MCP server itself, as CVE-2025-9611 showed.
• A compromised dependency that runs malicious code on install or update.
• Prompt injection, where a web page the agent visits contains instructions that persuade it to misuse another connected tool.
• Powerful optional tools. The Playwright MCP documentation describes an optional tool that can execute arbitrary JavaScript in the server process and warns that this is equivalent to remote code execution.

I like MCP. We built an Endtest MCP integration ourselves, and it also needs appropriate permissions and controls. But a vulnerability that once exposed one narrow operation becomes more consequential when the affected component is one link in a larger agent workflow.

Convenience doesn't eliminate security boundaries. It makes them easier to forget.

Is open source automatically more secure?

Open source has a real advantage: anyone can inspect the code. But being able to review code is not the same as reviewing it. Few teams read every npm dependency, the dependencies of those dependencies, or every change after an update.

The record shows both kinds of failure:

• Heartbleed (2014): an honest programming error in OpenSSL exposed process memory, in software that was open source, widely used, and critical.
• event-stream (2018): an attacker gained a maintainer's trust and introduced a malicious dependency into a popular npm package.
• XZ Utils (2024): a backdoor was planted in a widely used compression library and discovered before it spread widely.

Closed-source software has vulnerabilities too. The useful question isn't whether the source is public. It's whether someone is accountable for evaluating, patching, monitoring, and responding to risks in the system you're actually running.

That's also why an npm install deserves the same scrutiny as any other software approval. A package doesn't become safe because it's popular or because the repository belongs to a large company.

Does Microsoft guarantee Playwright's security?

Not in the contractual sense. Playwright was created by Microsoft engineers and is maintained under Microsoft's GitHub organization, which understandably creates confidence. It is also an open-source project under the Apache 2.0 license, which includes a standard disclaimer that the software is provided without warranties.

Microsoft's involvement is valuable. It does not mean your company has bought security guarantees, incident-response commitments, or an SLA for the Playwright installation on your laptop or CI runners. Playwright remains actively maintained, but the Microsoft name on a repository and a commercial support contract are two different things, and they should be evaluated differently.

What does ISO 27001 say about installing test tooling?

I coordinated the ISO/IEC 27001 process at Endtest, which has held the certification since 2020 and is audited externally every year. ISO 27001 doesn't promise that a company will never be breached. It's a standard for managing information security risk systematically, and two Annex A controls are directly relevant:

• Annex A 8.19, installation of software on operational systems: organizations need procedures for securely managing software installation, including authorization and controls.
• Annex A 8.8, management of technical vulnerabilities: organizations need to identify vulnerabilities, evaluate their exposure, and act on the risk.

This doesn't mean a developer needs a committee meeting to try a library. It means a company should know what software it runs, who approved it, what permissions it has, and who keeps it patched. That applies equally to commercial and open-source software, and to MCP servers connected to AI agents.

What is the hidden security cost of free test automation?

Playwright has no license fee. What it doesn't include is everything needed to operate it in production. You still provide or pay for:

• Machines or cloud infrastructure for browser execution.
• Storage for screenshots, videos, traces, and results.
• CI/CD execution and parallel browser capacity.
• AI tokens for coding agents and LLM-based automation.
• Supporting services for email, SMS, and other integrations.
• Security monitoring, vulnerability management, patching, and incident response.

In Why Playwright and Selenium Projects Fail, we documented a 90-day comparison at one customer:

That is one customer, not an industry benchmark, and other teams may see different results. The $225 was this customer's Pro plan with 1 parallel slot; Pro is normally sold with at least 2 slots ($450 a month on the current pricing page). It also didn't try to price the full security workload of running the Playwright stack: browser updates, access controls, cloud hardening, dependency scanning, audit evidence, and incident response. With a self-managed stack, most of that cost stays inside your organization.

What is a secure alternative to Playwright?

The most useful way to compare options is by operating model, not by license type. Here is who owns each piece of the security work:

The last row of responsibility never disappears. Customers still protect their credentials, configure access, and decide which applications their tests can reach. No honest vendor claims otherwise.

How Endtest approaches security

Endtest has been around for roughly ten years and has no known security breach in that time. That isn't a claim of immunity, because nobody has that. It reflects how long security and reliability have been design priorities. Here is what that looks like in practice:

• Managed real browsers. Tests run on real Windows and macOS machines, including real Safari, so you don't deploy browser hosts or track browser CVEs yourself. See Real Safari vs WebKit for why that matters beyond security.
• Explicit, editable steps. AI can generate tests, including through the autonomous Endtest Bot, but the result is readable steps rather than a script repository. Normal execution follows those steps and doesn't call an LLM each time.
• Certification and audits. ISO/IEC 27001 since 2020, with external audits every year. Details are on our security page.
• Abuse controls. We've seen people attempt to use cloud browsers for cryptocurrency mining. Any shared execution platform needs limits, monitoring, and the ability to respond.
• Fast patching. On October 20, 2026, the PHP security team announced critical fixes. PHP released updates the next day for two critical remote-code-execution vulnerabilities (CVE-2026-109618 and CVE-2026-109619), and we upgraded our PHP 8.4 infrastructure to 8.4.27 on October 21, the day the patch came out. No incident, no emergency redesign. That's the unglamorous part of security: when something needs patching, you patch it, using procedures built long before the announcement.

We also run an AI software factory internally, and a human engineer still reviews every change before production. The same principle applies to test tooling: automation should raise output without removing accountability. See Test Automation in AI Software Factories for how that works.

Which should you choose?

• Keep self-managed Playwright if you have engineers who own the browser infrastructure, a patching process, and sandboxed execution, and you want full control and tests living in your repository.
• Choose Endtest if you want AI-assisted test creation, editable steps, real browsers, and a provider that carries a large share of the infrastructure and security work. The trade-off is that tests live in a commercial platform rather than in your repo.
• Evaluate both on total cost of ownership, not only on license price. For a wider market view, see our roundup of the best AI-powered test automation tools and the Playwright vs Endtest comparison.

How do you secure a Playwright setup?

If you stay on Playwright, review these six areas:

1. Check versions. Confirm you run at least Playwright 1.55.1 and @playwright/mcp 0.0.40, and preferably current supported releases.
2. Inspect the actual browser builds. Updating the npm package doesn't guarantee a fully patched browser.
3. Review sandboxing and isolation. Remember that chromiumSandbox defaults to false. Don't let untrusted pages reach host files, internal networks, or credentials.
4. Audit every MCP server. List what's configured in Claude, Cursor, and other clients, which tools each one exposes, and what its process can do.
5. Apply least privilege. Use dedicated test identities, restricted credentials, isolated environments, and approval steps for sensitive operations. Keep secrets out of the environment variables of browser hosts.
6. Assign ownership. Someone has to monitor advisories, approve changes, deploy patches, and investigate suspicious activity.

Should you uninstall Playwright?

Not necessarily. If Playwright runs well for you, experienced engineers own its infrastructure, and your controls are sound, removing it over previously patched CVEs would be an overreaction.

But review the setup using the checklist above, and when you evaluate any test automation solution, include security and maintenance in the comparison. Don't judge Playwright only by what it costs to install, and don't judge Endtest only by its subscription price. Run a proof of concept, compare who owns which responsibilities, and calculate total cost of ownership.

The bottom line

I have nothing against Playwright as a technology. It's a capable framework that has made browser automation more accessible.

But we've developed a habit of treating popular open-source tools as inherently trustworthy while giving them extraordinary access to our systems, and of applying strict approval to commercial software while letting executable packages and MCP servers in with far less scrutiny.

Vulnerabilities aren't proof that a product is bad. The better questions are who detects them, who fixes them, who deploys the update, who monitors the environment, and who is accountable when something goes wrong.

With Playwright, those responsibilities fall on you and your team. With Endtest, a substantial part of that work is ours.

The right question isn't whether Playwright is free. It's whether you want to own and secure everything required to run it.

Frequently asked questions

Is Playwright safe to use in 2026?

Yes, when packages and browser dependencies are kept current, execution environments are isolated, and permissions are restricted. The two public CVEs (CVE-2025-59288 and CVE-2025-9611) are patched, but teams still own their broader infrastructure and security configuration.

Has Playwright been hacked?

We found no evidence that Playwright itself has been compromised or backdoored. There are two patched CVEs, and PostHog reported an incident in which a researcher exploited an outdated, unsandboxed Chromium running through Playwright. That was an infrastructure and patching failure rather than a flaw in Playwright's test API.

What are the known Playwright vulnerabilities?

CVE-2025-59288 affected Playwright before 1.55.1, where macOS installation scripts used curl -k and skipped certificate verification. CVE-2025-9611 affected @playwright/mcp before 0.0.40, which failed to validate the Origin header and allowed DNS rebinding. Both are fixed.

Is Playwright MCP a security risk?

It can be. Playwright MCP adds an interface between AI agents and browser automation, and its risk depends on version, exposed tools, network reachability, and process permissions. Older versions had a confirmed DNS rebinding vulnerability. Even current versions should run with access controls, least-privilege credentials, and review of every connected tool.

Should I uninstall Playwright because of these vulnerabilities?

No, not solely because of patched CVEs. Update to current versions, verify the browser builds, enable sandboxing, audit MCP servers, and decide who owns security. If you don't want to own that work, a managed platform is an alternative.

Is there a secure alternative to Playwright?

The alternative is a different operating model rather than a different logo. Managed platforms such as Endtest run real browsers, hosts, patching, and monitoring for you, with ISO/IEC 27001-certified processes. Self-managed frameworks can be equally secure only if your team operates and monitors them to the same standard.

Is Endtest more secure than Playwright?

They are different models. Endtest is a managed platform with ISO/IEC 27001-certified information security management and managed execution infrastructure. Playwright is a framework you deploy and secure yourself. A well-run Playwright installation can be secure, but Endtest reduces the amount of browser infrastructure and security work customers must operate themselves.

Does Microsoft guarantee Playwright's security?

No contractual guarantee comes with the open-source project. Playwright is Microsoft-led and licensed under Apache 2.0, which includes a warranty disclaimer. That differs from a commercial support agreement or SLA, so assess the responsibilities that apply to your deployment.

Is the Playwright browser sandbox enabled by default?

Playwright's documentation states that the chromiumSandbox option defaults to false. If your tests visit untrusted sites, review sandboxing and isolation deliberately instead of relying on defaults.

About the author

Liviu Lupei is the founder of Endtest and a Solutions Architect with 15 years of experience in Quality Assurance. He coordinated Endtest's ISO/IEC 27001 certification process and works with QA and engineering teams on automation infrastructure.

Sources and further reading

• GitHub advisory for CVE-2025-59288 (Playwright installer)
• GitHub advisory for CVE-2025-9611 (Playwright MCP)
• Playwright issue #43664: updated Chromium build
• PostHog security advisories
• Playwright MCP documentation
• Penligent: analysis of Playwright security vulnerabilities
• Endtest security page
• Why Playwright and Selenium Projects Fail (5,441-response survey + 90 days of cost data)

Last updated: November 3, 2026.