Selenium 4.48: Why the World's Most-Used Automation Framework Is Quietly Killing CDP for BiDi

If your test suite is built on Selenium, the last two releases deserve a closer look than a typical changelog skim. Selenium 4.48, published on August 27, 2026, is the latest step in a deliberate, multi-version campaign by the Selenium project to retire the Chrome DevTools Protocol (CDP) in favor of the W3C-standard WebDriver BiDi as the framework's default automation protocol — and it has real implications for how your suites talk to browsers.

What changed in 4.48

The headline items in the 4.48 release notes show the BiDi layer maturing across every language binding. The team continued strengthening the shared, binding-neutral BiDi layer: Ruby now rejects malformed inbound values, .NET throws on an unknown discriminator, and the JavaScript binding gained a new serialization and domain layer along with connection-level event subscription support.

Grid users also get a practical fix that's been a long-standing pain point for containerized pipelines: file upload and download now reliably work for Kubernetes, Docker, and relay-node sessions. Anyone running Selenium Grid on Kubernetes and hitting silent failures on file-transfer steps should update immediately.

The bigger story: 4.47 already switched off CDP for Firefox

The 4.48 release only makes sense in the context of what shipped about a month earlier. In version 4.47, the team took a decisive step: Firefox sessions now block CDP access entirely for the .NET, Python, and Ruby bindings, cementing BiDi as the sanctioned cross-browser protocol going forward. That release also made Grid's video capture more dependable, storing recordings in a consistent per-session subfolder — including on Kubernetes — instead of relying on the old pod-wait-and-relocate logic.

Together, 4.47 and 4.48 confirm a direction the project has been signaling since at least version 4.42, which shipped a BiDi "speculation module" and unified Dynamic Grid configuration between Docker and Kubernetes deployments. The pattern across releases is consistent: each one chips away at CDP dependency while hardening BiDi's reliability and cross-language consistency.

Why QA teams should care

CDP has long been the workhorse behind Selenium features like network interception, console log capture, and performance tracing — but it's a Chrome-originated protocol that behaves inconsistently, or isn't available at all, in other browsers. WebDriver BiDi is a genuine W3C standard, designed from the ground up to work identically across Chromium, Firefox, and WebKit-based browsers. For teams running cross-browser regression suites, that consistency is the entire value proposition of using Selenium in the first place.

The practical risk sits with any test code, custom framework, or third-party plugin that calls CDP directly for Firefox sessions — those calls will now simply fail on 4.47 and later. Before upgrading, it's worth auditing your suite for:

• Direct Chrome DevTools Protocol calls or CDP-based network mocking used against Firefox targets
• Custom logging or tracing hooks built on CDP session objects
• Grid deployments on Kubernetes or Docker that rely on file upload or download steps in tests
• Any wrapper library or in-house automation framework still pinned to a pre-4.42 Selenium release

The takeaway

None of this arrives as a single dramatic "breaking change" announcement — it's a steady, release-by-release migration that's easy to miss if you only skim major-version headlines. But for test architects planning their 2026-27 automation roadmap, the signal from the Selenium project is now unambiguous: build new automation on BiDi rather than CDP, and set aside time to migrate anything that still leans on Chrome-specific hooks, especially where Firefox coverage is involved.