GitHub Blocks pull_request_target, Forwarded Header Spoofing and Psalm 7: Developer News for November 8, 2026

Submitted by jaypabs on Sunday, November 8, 2026 - 11:35.

It is the weekend, but a few things from the past week need your attention before Monday, especially if you keep projects on GitHub or run a web app behind a proxy. Here is a plain-English roundup for November 8, 2026, with links to the original announcements so you can check every detail yourself.

All numbers and dates below come from the linked sources. Where a company is describing its own internal tests, that is labeled as its claim.

1. GitHub Will Block pull_request_target by Default on December 2 (First Brownout Is Monday)

GitHub announced that starting December 2, 2026, GitHub Actions will block pull_request_target events by default in all public repositories, unless an Actions event policy explicitly allows them. Enforcement had been planned for November 2 and was moved back a month. Private and internal repositories are not affected, and neither is GitHub Enterprise Server.

Why this matters: a pull_request_target workflow runs in the context of your base repository and can read its secrets. If that workflow checks out and runs code from a fork, someone can open a pull request that steals your tokens.

Before the permanent switch, GitHub will enforce the rule during two short brownouts:

November 9, 2026, 16:00 to 18:00 UTC (that is 12:00 AM to 2:00 AM on November 10, Philippine time)
November 16, 2026, 16:00 to 18:00 UTC (12:00 AM to 2:00 AM on November 17, Philippine time)

During those windows, blocked workflows will show up as failed runs with an error annotation. What to do: search your .github/workflows folder for pull_request_target. If a workflow does not truly need it, switch to the safer pull_request event. If it does, GitHub says to allow it in an Actions event policy and target only the specific workflow files that need it. You can check which runs would be blocked in the rule's Insights view.

2. Rails, Spring and Jetty Can Trust a Spoofed "Forwarded" Header

Security researcher Lauri Koskela published a write-up called Forwarded Without Question on November 5. The short version: some web frameworks read the standard Forwarded header (RFC 7239) in their default or near-default setup, while most reverse proxies, CDNs and load balancers only handle the older X-Forwarded-* headers and pass Forwarded through untouched. A client can then send its own Forwarded: for=... or host=... value and the app may believe it.

In his tests, Rails 8.1, Jetty and Spring Boot (before 4.2, with forwarded header handling enabled) preferred Forwarded over the proxy's X-Forwarded-For. Possible impact includes bypassing IP-based access rules and rate limits, fake IP addresses in logs, and, when the host can be spoofed, poisoned password reset links or cache poisoning. Of the frameworks he checked, Django, Express, ASP.NET Core and Werkzeug did not read Forwarded.

Fixes are rolling out. Rails published advisory GHSA-2gff-2mmg-m73p (rated High) for actionpack 8.1.0 through 8.1.4; the patched version is 8.1.4.1. According to the write-up, Spring Boot 4.2 now parses only X-Forwarded-* headers by default, while Jetty kept its documented default but made the behavior easier to configure.

What to do: make your edge proxy (Nginx, Apache, Caddy, Traefik and so on) remove or overwrite incoming Forwarded and X-Forwarded-* headers, and configure your framework to trust only the headers your proxy actually sets. If you use PHP and Symfony, the research notes that Symfony needs Forwarded to be explicitly enabled and rejects conflicting values, but host spoofing can still be possible if you turn it on.

3. Psalm 7 Turns On Security Analysis by Default for PHP

The PHP static analysis tool Psalm 7 was released on November 2. The headline change for most teams: taint analysis (security analysis) now runs by default, in the same pass as type checking and dead code detection, and the project says it is up to 10 times faster than before. Taint tracking follows untrusted input such as $_GET, php://input and uploaded file names into dangerous sinks like SQL queries, shell commands and eval(), and it adds new checks for NoSQL, LLM prompt injection and URL injection.

Psalm 7 runs on 64-bit PHP 8.2 to 8.6, understands the PHP 8.5 pipe operator and PHP 8.6 partial function application, and bundles the PHPUnit, Symfony, Laravel, Mockery and sabre/event plugins so they switch on automatically. Upgrading is usually composer require --dev vimeo/psalm:^7.0 -W. Expect new security warnings on your first run; that is the point.

4. Babel 8.1.0 Adds Bytes and Text Imports

Babel 8.1.0, the first minor release after Babel 8.0, came out on November 2. It adds transform plugins for the Import Bytes (Stage 2.7) and Import Text (Stage 3) proposals, which let you write import logo from "./logo.png" with { type: "bytes" } or import a file as a plain string. It also ships a plugin for filtered namespaces, experimental source maps with range mappings, parser support for import.sync, deferred re-exports and non-shared structs, and new recommended and all configs for @babel/eslint-plugin. These are mostly proposals, so treat them as something to experiment with rather than production defaults.

5. PyCharm 2026.3 Brings JetBrains Air and Python 3.15 Lazy Imports

JetBrains released PyCharm 2026.3 on November 5. The centerpiece is JetBrains Air, a layer for running, tracking and reviewing coding agents inside the IDE. JetBrains says it works with Claude Agent, Codex, Gemini, GitHub Copilot, Junie, OpenCode and other ACP-compatible agents, accepts your existing provider subscriptions or API keys, and includes a free Junie Lite configuration that only needs a JetBrains Account. For everyday Python work, the release also adds per-subproject consoles and terminals for workspaces (including uv workspaces), initial support for Python 3.15 lazy imports, interactive FastAPI dependency graphs and deeper Pydantic inspections.

6. GitHub Explains "Rubicon", Its New Git Storage for Agent-Heavy Repos

On November 5, GitHub's engineering blog described the new Git storage architecture announced at GitHub Universe, code-named Project Rubicon. According to GitHub's internal testing, it supported 5,000 concurrent agents working on one repository and 7,200 pushes per second to a single repo. The core idea is simple: Git objects are immutable, so only reference updates (moving a branch to a new commit) need coordination. Objects live in Azure Blob Storage, references live in a small replicated compare-and-swap service called Ref-CAS, and pack compaction runs on separate background nodes.

For regular developers nothing changes: you still push, fetch and branch the same way. GitHub says the architecture is in limited private preview now, with a broader rollout early next year.

Coming Up This Week

November 9 (UTC): first GitHub Actions pull_request_target brownout.
November 10: Python 3.16.0a2 is scheduled, according to Real Python's November news roundup. It is an early alpha, so do not use it for school or production projects.
November 16 (UTC): second brownout, ahead of enforcement on December 2.

Quick Checklist

Grep your public repos for pull_request_target before Monday's brownout.
Rails 8.1 apps: upgrade actionpack to 8.1.4.1 and strip client-supplied Forwarded headers at the proxy.
PHP projects: try Psalm 7 on a branch and read the new security findings.

Search