Mid-Season Tweaks and a Tiny CVE: Keeping F1 Telemetry Honest in 2026
- Tim Harmon
- 16 hours ago
- 7 min read
By Timothy D. Harmon, CISSP Lead Enterprise Architect | Cyber-Physical Telemetry (Formula 1) | Credentialed MSUK & SCCA Official | Cisco Insider Champion
Mid-season rule changes are awkward for anyone who builds tools on top of Formula 1 data. The FIA tweaks a few numbers in the power-unit regulations, teams quietly adjust their models, and every third-party validator that hard-coded last month’s thresholds suddenly thinks half the grid is cheating.
This year, those tweaks landed at the same time as a small but real security issue in the Python requests library, which underpins many telemetry gateways and dashboards. Put together, they’re a good reminder that “keeping F1 telemetry honest” is not just a Monaco-style governance problem — it’s also about staying current with both the rulebook and your dependencies.
This article walks through the 2026 mid-season energy-management changes, what they mean for telemetry validation, and why a seemingly niche requests CVE still deserves a place in your change log.
The FIA just moved the goalposts
In April 2026, the FIA World Motor Sport Council approved a package of refinements to the 2026 Formula 1 regulations, focused entirely on energy management and driveability rather than aerodynamics.
The key changes were:
Recharge cap reduced from 8MJ to 7MJ per lap. The maximum permitted energy recovery per lap has been cut from 8MJ to 7MJ, with the explicit aim of reducing extreme harvesting strategies and encouraging drivers to run more of the lap flat-out.
Superclip power increased from 250kW to 350kW. The peak power available during “superclipping” (harvesting while on full throttle) has been raised to 350kW in both qualifying and races, up from 250kW.
Race boost capped at +150kW. The maximum additional power available from Boost in race conditions is now capped at +150kW above the car’s current power level at the moment of activation, limiting sudden closing-speed differentials in unexpected places.
350kW vs 250kW deployment zones. MGU-K deployment remains at 350kW in key acceleration areas — corner exit to braking points, including overtaking zones — but is limited to 250kW elsewhere around the lap.
A new low-power start detection system. The regulations now include a low-power start detection mode that identifies cars with abnormally low acceleration just after clutch release, automatically deploys the MGU-K to guarantee a minimum launch, and activates flashing rear and lateral lights to warn following drivers.
From the FIA’s perspective, these are small-print changes aimed at making the cars more drivable, the racing more consistent, and the starts safer. From a telemetry-validation perspective, they’re a hard change to the definition of “normal.”
Why hard-coded thresholds break fast
Most engineering and governance dashboards boil down to two (2) ingredients:
Telemetry fields — values such as ers_rechardge_mj, ers_deploy_kq, boost_state, and mguk_mode.
Assumptions about what those fields are allowed to do — maximum recharge per lap, legal deployment windows, and where Boost is expected to show up.
When the FIA tightens the recharge cap from 8MJ to 7MJ and raises superclip power to 350kW, they have effectively:
Lowered the “legal ceiling” for harvested energy per lap; and
Raised the “legal ceiling” for instantaneous electrical power delivery on straights.
Any validator that bakes in the old ceilings without versioning will react in one of two bad ways:
False positives. A car that legitimately superclips at 340–350kW gets flagged for “excessive deployment” because your model still thinks 250kW is the maximum.
Silent blind spots. A car that consistently hovers at 7MJ recovery looks fine to a model that still expects 8MJ, but the real opportunity is now in how efficiently it uses that smaller budget.
The new low-power start detection system adds a different kind of risk. If you don’t capture the presence of that ECU-driven MGU-K launch assist and the associated warning lights, your replay tools and incident reviews will be missing a piece of the causal chain for any start-line drama.
For any “independent validator” story, those are credibility-destroying mistakes. If you claim to test the sport’s own tools, you can’t lag the sport’s own numbers.
A small Python CVE with real governance implications
At the same time these F1 tweaks were rolling out, the Python ecosystem picked up another entry in the requests vulnerability catalog: CVE-2026–25645, an insecure temporary-file issue in requests.utils.extract_zipped_paths().
The short version:
Prior to requests 2.33.0, extract_zipped_paths() used predictable filenames when extracting ZIP archives into the system temporary directory.
If a file with that expected name already existed, it would be silently reused without any integrity or ownership checks.
A local attacker with write access to the temp directory could pre-create a malicious file with that name, then wait for your applications to extract a ZIP and load the attacker-controlled file instead.
The good news is that normal HTTP usage of requests is not affected; only applications that explicitly call extract_zipped_paths() are in the blast radius. The fix in 2.33.0 moved extractions to non-deterministic locations and closed the predictable-name loophole.
However, CVE-2026–25645 isn’t the only reason to upgrade. Two earlier issues are also worth closing out:
CVE-2023–32681 — Proxy-Authorization header leak on HTTPS redirects. Versions 2.3.0 through 2.30.0 could leak Proxy-Authorization headers to destination servers during certain HTTPS redirect patterns; this was fixed in 2.31.0.
CVE-2024–35195 — certificate-verification bypass after verify=False. Prior to 2.32.0, if the first request in a Session to a given origin used verify=False, subsequent requests to that origin would continue to skip certificate verification even if verify=True was set later.
Security audits now list requests 2.34.2 as the current stable release and recommend upgrading to at least 2.33.0 to clear CVE-2026–25645, and to at least 2.32.0 to clear CVE-2024–35195.
For a typical telemetry gateway that:
Uses requests.Session.post() to send events into Splunk or another data lake, and
Runs in an environment where multiple users or processes share a temp directory,
this matters less because you’re calling extract_zipped_paths() and more because you don’t want a TLS or proxy quirk to undercut the guarantees you think you’re making about your own data.
If the whole point of your tool is “independent, trustworthy telemetry, “ leaving known issues in your HTTP library is an avoidable own goal.
How I applied this to my own telemetry stack
In my own F1-focused telemetry experiments, I had done what many of us do: pinned requests to a conservative, “known good” 2.31.0 and then lived there for longer than I should have. It was stable, my Splunk HEC POSTs worked, and nothing was on fire.
The mid-season rule changes and the new CVE were a good excuse to clean house.
1. Bump requests and pytest
The dependency side was straightforward:
Upgrade requests to a version that clears all three issues
◦ CVE‑2023‑32681 (proxy header leak) — fixed in 2.31.0.
◦ CVE‑2024‑35195 (Session verify stickiness) — fixed in 2.32.0.
◦ CVE‑2026‑25645 (insecure temp files) — fixed in 2.33.0
With 2.34.2 available on PyPI and flagged as current in recent security audits, targeting that release gives some future-proofing.
Upgrade pytest to the latest minor version in the same major line, then run the full test suite to verify that behavior around fixtures and parametrization is unchanged in the area my telemetry tests rely on.
I also grepped the codebase for extract_zipped_paths() to confirm I wasn’t calling it directly, which meant CVE-2026–25645 was theoretical rather than immediately exploitable in my case—but still worth eliminating.
2. Align ERS constants with the updated 2026 regulations
On the F1 side, the validator already modeled ERS limits as constants, so the work was:
Confirming that ERS_MAX_RECHARGE_MJ was set to 7.0 MJ, not 8.0.
Ensuring the superclip and deployment constants reflected 350kW in key zones and 250kW elsewhere, with Boost capped at +150kW above current power.
Adding a simple boolean or state field in the telemetry schema to represent whether FIA’s low-power start detection system had intervened on a given launch, plus the associated warning-light state.
Finally, I updated comments and documentation alongside those constants with direct references to the FIA’s April 2026 refinement announcement, so that six months from now I’ll still remember why the numbers look the way they do.
Telemetry as a living thing
None of these changes are glamorous. There’s no new anomaly-detection algorithm here, no “AI for race strategy,” no dramatic Monaco-style governance scandal. Just:
A 1MJ tweak to the recharge cap.
A 100kW bump in superclip power.
A new launch-safety mode.
A couple of CVEs in an HTTP library.
But that’s the point. If your goal is to keep F1 telemetry honest — to build tools that can stand up in front of teams, stewards, or even courts — you don’t just need big-bang corrections. You need ongoing alignment with a moving rulebook and a moving software supply chain.
For 2026, that looks like:
Treating FIA refinement bulletins as configuration inputs, not trivia.
Treating pip install -U and a quick CVE sweep as part of race-week prep, not a once-a-year chore.
And teaching your tools to understand the difference between “this is weird because the car is cheating” and “this is weird because the world changed and I forgot to tell my validator.”
That’s not as cinematic as a 77-centimetre timing error flipping a podium. But if you care about integrity, it’s where most of the real work lives.
This article was originally published on LinkedIn on August 20, 2026.
Timothy D. Harmon, CISSP, is a Lead Enterprise Architect, motorsport official, and the author of Project Apex, a 2026-focused cyber-physical telemetry validation concept for Formula 1. He presented “Hacking Physics at 300 KPH” at BSides San Diego 2026 (pictured below) and writes at The Secure Accelerator.
References
Formula 1. (2026, April 19). F1’s urgent mid-season rule changes explained [Video]. YouTube. https://www.youtube.com/watch?v=gID76mhl6TM
Formula 1. (2026, April 19). Refinements to 2026 F1 regulations agreed by all stakeholders. Formula 1. https://www.formula1.com/en/latest/article/refinements-to-2026-f1-regulations-agreed-by-all-stakeholders.1xA0TRau0DvyId6R7oZjFv
GitHub. (2023, May 26). Unintended leak of Proxy-Authorization header in requests (GHSA‑j8r2‑6x86‑q33q). GitHub Security Advisories. https://github.com/psf/requests/security/advisories/GHSA-j8r2-6x86-q33
GitHub. (2024, May 19). Requests Session object does not verify requests after making first request with verify=False (GHSA‑9wx4‑h78v‑vm56). GitHub Security Advisories. https://github.com/psf/requests/security/advisories/GHSA-9wx4-h78v-vm56
National Institute of Standards and Technology. (2026, March 25). CVE‑2026‑25645 detail. National Vulnerability Database. https://nvd.nist.gov/vuln/detail/CVE-2026-25645
OSV. (2024, May 19). CVE‑2024‑35195 — OSV [Vulnerability record]. Open Source Vulnerabilities. https://osv.dev/vulnerability/CVE-2024-35195
Reddit. (2026, April 20). Refinements to the 2026 FIA Formula 1 regulations agreed by all stakeholders [Online forum post]. r/formula1. https://www.reddit.com/r/formula1/comments/1sqtnit/refinements_to_the_2026_fia_formula_1_regulations/
Snyk. (2026, March 25). Insecure temporary file in requests (CVE‑2026‑25645). Snyk Vulnerability Database. https://security.snyk.io/vuln/SNYK-PYTHON-REQUESTS-15763443
The Race. (2026, April 19). F1 agrees package of mid-season 2026 rule changes. The Race. https://www.the-race.com/formula-1/f1-2026-mid-season-rule-changes/
Twingate. (2026, March 1). CVE‑2023‑32681 report — Details, severity, & advisories. Twingate. https://www.twingate.com/blog/tips/cve-2023-32681
VersionEye. (2025, June 8). Python/requests/2.16.0. VersionEye. https://www.versioneye.com/Python/requests/2.16.0
Williams Racing. (2026, April 20). Agreed changes to 2026 F1 regulations to debut in Miami. Williams Racing. https://www.williamsf1.com/articles/38efd2e4-0901-47c5-85c0-7e48011f4a4f/agreed-changes-to-2026-f1-regulations-to-debut-in-miami
Comments