Yet another security vulnerability has been discovered in GitLab infrastructure, this one a perfect 10 in severity.

CVE-2026-85706, the second flaw GitLab has disclosed in just a month, is a maximum-severity vulnerability that allows attackers to read arbitrary files in a single HTTP request. The path traversal flaw results from improper confinement and lack of authentication enforcement in GitLab’s repository commits API, the company reported.

Threat actors could exploit it “under certain conditions” and read arbitrary files (credentials, secrets, and other sensitive data) on vulnerable GitLab servers.

The company has fixed the vulnerability, which impacts GitLab Community Edition (CE) and Enterprise Edition (EE), and has advised customers with public-facing self-hosted GitLab instances to patch their servers immediately, or remove public access.

Experts say the flaw is alarming because GitLab’s DevSecOps platform is used by roughly 50% of the Fortune 100 and has more than 50 million estimated registered users.

“GitLab is not simply a source-code repository,” noted Safayat Moahamad, advisory director at Info-Tech Research Group. In many enterprises, it is connected to build pipelines, deployment processes, application security workflows, and other trusted systems.

As a result, unauthorized access to configuration files, secrets, or credentials on the GitLab server could “create consequences well beyond the affected instance,” he said.

Don’t wait for the normal patch cycle

GitLab has been a favorite hacker target of late: In January, it patched a high-severity flaw that allowed attackers possessing a target’s account ID to bypass two-factor authentication, and in August, it fixed a critical vulnerability that could give unauthenticated users the ability to make modifications inside code repositories or even completely delete them with a single HTTP request.

The current maximum severity bug, CVE-2026-85706, was reported through GitLab’s HackerOne bug bounty program. It affected CE and EE versions 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2.

The US Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog, noting that this type of vulnerability is a frequent attack vector for malicious cyber actors, and particularly poses significant risks to the federal enterprise; watchTowr Intel has reported that it is already observing “in-the-wild probes.” “Based on recent GitLab vulnerabilities, we know the time until indiscriminate exploitation is likely not far away,” it warned.

This is not a vulnerability that organizations should leave for the normal patch cycle, Moahamad emphasized. “It offers an unauthenticated path to arbitrary files on a platform that frequently sits at the center of source code, build, and deployment workflows,” he said.

Enterprises should patch immediately, hunt for suspicious repository-commits API activity, and investigate whether exposed files contained credentials or secrets that may now require rotation, he advised.

Beyond patching, the watchTowr Intel team said defenders should try to identify exploitation attempts by hunting through log files for HTTP POST requests to “/api/v4/projects/{id}/repository/commits/” URIs containing “file.path” parameters.

CI/CD platforms are critical trust infrastructure 

Organizations running affected self-managed GitLab CE or EE instances should be most concerned, Moahamad noted. Risk increases where GitLab is connected to sensitive repositories, CI/CD pipelines, cloud environments, or production-deployment processes.

The information and/or access that attackers could obtain depends on what the GitLab service can read and what organizations store on the server, he explained. It could include configuration files, secrets, credentials, and other sensitive server-side data. If those files happen to contain usable tokens, keys, or credentials, an attacker could attempt to access connected infrastructure

“The flaw directly creates an unauthorized file access risk,” he said. Credential theft, lateral movement, source code exposure, and supply chain compromise are possible follow-on scenarios.

Source code and CI/CD platforms must be governed as “critical trust infrastructure,” he said. While patching remains essential, resilience will depend on knowing where platforms can be exposed, limiting what they can access, detecting abnormal API behavior, and having a tested process for investigating and rotating credentials.

David Shipley of Beauceron Security described two factors colliding to generate “maximum pain” for GitLab users.

First is the vulnerability. “It’s a 10 for a reason: Unauthenticated read access to GitLab client source code,” he said.

Second, this especially hurts because developers still have bad habits: way too much code continues to ship or is in production with embedded SSH keys, cloud secrets, tokens, and other valuable data that attackers can use to get into infrastructure, Shipley said.

“So for attackers, you’ve got the classics,” he noted: Data exfiltration and extortion, ransomware, cloud infrastructure hijacking for crypto mining, and the stealing of AI tokens and infrastructure to enable other criminal activity.

“This level of vulnerability is the code and cloud equivalent of being able to get the credit card number, expiry and security number,” Shipley said. “It opens up a world of criminal data shopping.”

The bottom line: “Get those secrets out of production code and adopt modern coding authentication best practices,” he advised.

This article originally appeared on CSOonline.

Stung by a surge in cyberattacks that have run amok in developer environments, GitHub has strengthened the security of actions/checkout to block ‘pwn request’ attacks that exploit insecure use of the pull_request_target workflow trigger to run an attacker’s code with the workflow’s full privileges.

Announced on June 18, actions/checkout v7 now automatically blocks and fails workflows when used inside pull_request_target or workflow_run events when attempting to fetch unreviewed fork pull request code.

From now on, the only away around these checks will be for developers to implement an opt out by adding an explicit allow-unsafe-pr-checkout to actions/checkout, GitHub said in its V7 changelog.

The change signals the beginning of a new ‘secure by default’ era in which security will be defined by the GitHub system rather than being left to discretion of developers. As part of that effort, on July 16, the new defaults will be backported to all supported major versions.

“Workflows pinned to a floating major tag (e.g., actions/checkout@v4) will automatically pick up the change. Workflows pinned to a specific SHA, minor, or patch version aren’t affected by the backport and will need to upgrade using Dependabot or through established upgrade processes,” GitHub explained.

However, because pwn request attacks can happen in other ways, “further hardening of additional events may be explored in future releases,” the changelog added.

Blind spot

If there’s a criticism that can be levelled at GitHub over this, it’s that it has taken so long to address a weakness that’s been known about for years.

The issue is with GitHub Actions, which allows triggers to run workflows, including pull_request, which processes third-party forks without giving access to secrets such as API keys, service tokens, and credentials. The downside is that this restriction prevents some automations from working, which is why developers turn to an alternative trigger, pull_request_target, which grants the required access.

At some point, attackers realized that where pull_request_target was configured carelessly with actions/checkout to pull in untrusted fork code, it offered a back door into repositories and their secrets.

In other words, the weakness in pull_request_target isn’t the trigger itself, which is legitimate and secure when correctly used, but in its  incorrect use. As GitHub’s changelog puts it: “Checking out the head of an unreviewed pull request from a fork inside one of these workflows typically lets attacker-controlled code execute with the workflow’s full privileges.”

The arrival of actions/checkout v7, however, should make this harder, automatically blocking risky workflows regardless of their configuration.

Unfortunately, a lot of damage has already been done. Open source repositories have recently come under sustained attacks from the TeamPCP hacking group, using a variety of techniques, including pwn requests.

A notable example was its attack last month, which compromised 170 node package manager (npm) packages, including the TanStack Router ecosystem, thanks to a pwn request exploit. Embarrassingly, in a separate incident not involving a pwn request, GitHub itself was breached and the attackers exfiltrated source code from around 3,800 of the company’s internal repositories.

Better late than never, GitHub has sprung into action, plotting a series of security reforms on the platform, including, earlier this month, limiting automatic install script execution in npm.

The ability for attackers to leverage automatic install script execution in npm will finally come to an end when expected changes arrive from GitHub in July. Coders will still be able to enable the function, but the default setting will block it. 

In V12, default settings are changing, GitHub said in its changelog, noting, “it turns an npm install behavior that runs automatically today into one you explicitly opt into.” 

Specifically, the post said, “allowScripts defaults to off: npm install will no longer execute preinstall, install or postinstall scripts from dependencies unless they are explicitly allowed in your project. This includes native node-gyp builds; a package with a binding.gyp and no explicit install script still gets blocked, because npm runs an implicit node-gyp rebuild for it. Prepare scripts from git, file, and link dependencies are blocked the same way.”

Analysts, consultants, and users generally applauded the change, but said that it would only narrow the exposure to supply chain attacks instead of eliminating it. 

Attacks likely to move elsewhere

Sonu Kapoor, maintainer for CVE Lite CLI in the OWASP Incubator Project, said that this change is likely to force the supply chain attacks that leveraged the automatic execution to move elsewhere.

“This does not eliminate npm supply chain risk, it removes a major automatic execution path,” Kapoor said. “Attackers can still move to other paths: malicious package code that runs at application runtime, compromised maintainer accounts, dependency confusion, typo-squatting, poisoned GitHub Actions workflows, malicious transitive dependencies, or stolen publishing tokens. This closes one very dangerous door, but it does not secure the whole house.”

Still, attacks leveraging the setting have been regularly used in supply chain attacks. 

However Alan Parkinson, director of secure medical device firm Threat Detective, said more sophisticated attackers have already moved beyond this hole. 

“The install script attack vector has been known for years,” Parkinson said. “Most security teams marked it as low risk and moved on to higher risk threats. What raised its profile wasn’t the technical exploitability changing, it was a run of high-profile victims and some threat actors openly chasing notoriety.”

He added, “the pre and post install scripts was never a clever attack vector to begin with. Running code from an install hook is crude and noisy, which is why it caused such visible damage. The more capable actors are already moving to other methods, so v12 mainly shuts the door on less sophisticated threat actors.”

Although GitHub declined an interview, Zach Steindler, a GitHub principal engineer, answered InfoWorld’s questions by email. He said the volume and pace of supply chain attacks forced the default settings change. 

“We’ve seen attackers target these capabilities to quickly propagate attacks from one compromised package to many. Years of security and usability research have shown that it’s not enough to make secure functionality available; the secure path has to be the default in order for it to be widely adopted,” Steindler said.

He added, “we believe that these changes are a great way to provide high impact secure defaults while still providing the option for some users to fall back on functionality they might need in some circumstances.”

Change overdue

Sanchit Vir Gogia, chief analyst at Greyhound Research, said that GitHub was the last of the repositories to make the setting default change. “Rivals moved first: Yarn, pnpm and Bun all block third party install scripts by default in their own ways,” Gogia said. “Npm is not inventing a new doctrine. It is finally adopting one.”

Steindler didn’t dispute Gogia’s comment. 

“It’s not easy being the stewards of the largest package repository in the world. Community consensus on what security capabilities should be standard, and when it’s okay to make breaking changes shifts over time. From our continual conversations with the community, it was clear it was time to make this change,” Steindler said.

“The recent attacks are alarming,” he noted, “but stewarding these package repositories is a multi-decade effort, not just a moment in time. As attacks evolve, so will our defensive security capabilities. We’re in this for the long haul.”

Gogia said that the change, although overdue, is a good one. 

“Npm is removing one of the most comfortable hiding places for software supply chain risk: code that executes the moment a developer types install,” Gogia said. “With npm v12, execution becomes something that must be approved, recorded in the project, and committed for review. That is not a design adjustment. It is a change in control philosophy.”

Bad defaults become infrastructure

Gogia had his own take on why GitHub waited so long.

“Npm waited because its risky default acquired a constituency. As far back as 2016, npm’s own position was that the convenience of install scripts outweighed the worm risk, with an opt-out flag for the cautious. The trade-off was a documented product decision, not an oversight,” he said.

“The trouble with bad defaults is that they become infrastructure,” he added. “Native module builds, browser installers such as Playwright and Cypress, Electron download flows and Husky hooks all grew around automatic execution. Turning it off became less a technical adjustment and more a constitutional reform.”

Liability changed hands

The real pressure for the change, however, came from regulators.

“The deeper answer is that the liability changed hands. Once regulation such as the EU Cyber Resilience Act and securities disclosure rules placed supply chain failure on corporate balance sheets, a documented unsafe default became indefensible,” Gogia said. 

Kapoor agreed that long-used procedures enabled this security hole to survive longer than it should have. 

“The reason this likely was not done long ago is compatibility,” he said. “Install scripts are not only used by attackers. Many legitimate packages use them to compile native modules, download platform-specific binaries, generate files, or complete setup steps. Changing the default breaks assumptions that have existed in the npm ecosystem for years. That is why these security changes often arrive slowly. The safer default is obvious from a security perspective, but painful from an ecosystem compatibility perspective.”

In addition, he noted, “the bigger point is that package managers are moving from implicit trust to explicit trust. That is the right direction. Developers should have to approve which dependencies are allowed to execute code during install. But approval cannot become a blind checkbox. Teams need visibility into which package wants to run a script, whether it is direct or transitive, why it is there, and whether it belongs in the project at all.”

Kapoor added that this change matters because install-time execution often happens in privileged environments with access to tokens, secrets, internal registries, build artifacts, or deployment paths. “Even if the script does not compromise production directly, it may be able to steal enough context to support the next stage of an attack,” he said.

Value in the pain

Cybersecurity consultant Brian Levine, executive director of FormerGov, agreed that the closing of this security hole is a very good thing. 

“It seems like virtually every major supply chain attack of the last decade has had the same original sin: code that ran automatically because the ecosystem let it. Npm finally closing that door by default is overdue, but it’s genuinely significant. This is the package manager for hundreds of billions of downloads a month,” Levine said.

“When npm changes its defaults, it changes the security posture of practically every enterprise dev environment on the planet. It may have been the last large code repository to still allow this kind of automated execution.”

Levine added that this change might not merely stop a security hole, but the new process may meaningfully improve security. 

“There’s actually something valuable buried in this migration pain. Having developers explicitly approve which packages can run code and commit that list to source control is a form of software supply chain governance that many organizations never had,” Levine said. “It creates an auditable record which is meaningful, especially for regulated industries.”

GitHub is expanding Copilot beyond the IDE with a new desktop application and a new collaborative work surface called canvas as part of its broader efforts to pitch the AI-assisted coding tool as the control center for agent-native software development.

The desktop application announced at Microsoft’s annual Build conference this week is designed to give developers a dedicated environment for working with AI agents throughout the software development lifecycle, rather than limiting those interactions to code-generation tasks inside an editor, the company wrote in a blog post.

The application includes a collaborative workspace called canvas where developers can brainstorm ideas, refine requirements, generate plans, and iterate on projects alongside AI, it said.

It also has new Agent Merge and code review features that enable developers to automate Copilot to combine tasks of different agents to complete a specific goal or conduct autonomous code reviews according to set standards, it said.

These new features could reduce context switching, increase engineering efficiency, and accelerate delivery cycles, said Phil Fersht, CEO of HFS Research.

Shift in pricing justified?

However, despite the new features, much of the conversation among developers in recent weeks has centered on a different topic: this week’s shift to a usage-based billing model for GitHub Copilot that it announced in April.

The changes were met with a wave of criticism on the GitHub community forum, where some users accused the company of a “bait and switch,” while others requested refunds or announced plans to cancel their subscriptions.

For analysts, though, the pricing change was, at least from GitHub’s point of view, necessary and justified.

“The pricing change is justified by where GitHub is going, not by where the product is today. Running multiple agents in parallel with sandboxes, canvas reviews, and Agent Merge looping through CI is closer to cloud compute than an IDE plugin, and you cannot price compute on a flat seat fee. So metered billing is the right call structurally,” said Advait Patel, a senior reliability engineer at Broadcom.

Fersht said developers and CIOs need to focus on Copilot’s metamorphosis from being a coding assistant into a platform for orchestrating software-development agents and workflows.

“That changes the ROI conversation significantly. CIOs should stop thinking about Copilot as a seat-license productivity tool and instead evaluate it as an AI-powered software delivery platform,” he said. “The metrics shift from ‘lines of code generated’ to broader operational outcomes such as release velocity, code quality, defect reduction and engineering efficiency.”

GitHub is not the first company offering vibe-coding tools to rethink its pricing strategy as AI agents proliferate across enterprises and evolve to take on more complex software-development tasks that are computationally more intensive.

Over the past year, platforms such as Claude Code, Replit, Cursor, and Kiro have repeatedly adjusted their pricing structures to account for mounting infrastructure costs, limited GPU availability, and the expense of serving increasingly sophisticated AI models and agents, despite furor among their users.

For CIOs, the challenge is proving ROI

That common pressure across AI coding vendors is why Amit Chandak, chief analytics officer at IT consulting firm Kanerika, thinks developers and CIOs should focus less on GitHub’s pricing mechanics and more on whether these increasingly capable tools are delivering measurable business value.

“The new features that GitHub announced can act as productivity multipliers as well as features that increase consumption without delivering proportional business value. Without productivity baselines established before adoption, enterprises risk absorbing higher costs with no clear line back to delivered value,” Chandak said.

For Fersht, developers and CIOs will need to focus on governance, monitoring and financial controls as the pricing model is changing.

“The governance challenge is very real. Autonomous agents can continuously reason, test, revise and interact with multiple systems in ways that create far less predictable consumption patterns than traditional SaaS tools,” he said.

Patel, however, advised users and decision-makers to be more skeptical, especially since the new features are currently in technical preview.

“Customers are being asked to pay variable rates now for value that has not been validated in production. Do not assume new capabilities justify higher spend,” he said. “Instead, run a 90 day pilot, measure PRs merged per dollar before and after, and let the data decide. If the ratio improves, the pricing is fair. If it does not, you are paying for promise, not delivery,” Patel added.

A vulnerability in GitHub’s browser-based VSCode editor could lead to the theft of a developer’s token under certain circumstances, says a researcher.

The issue, revealed this week in a blog by Ammar Askar, has apparently been already addressed by GitHub owner Microsoft. But it raises a questions about both DevOps security, and about the researcher’s allegation that, because Microsoft doesn’t treat bug discoveries seriously, he can justify giving it short notice before openly publishing vulnerabilities he finds.

First, the bug: Users of github.com may not realize it, but when they are on any repository, they can shift to github.dev and its browser-based version of VSCode just by changing the URL.

Why do this? Because the browser instance of VSCode is pretty powerful, Askar says in his blog. “You can view all the files in the repo (even if it’s a private one), you can send out pull requests, and even make commits.”

Rob Enderle, a IT consultant who heads the Enderle Group, agrees that jumping into VSCode this way is “an incredibly useful tactical tool for quick tasks. By just hitting the ‘.’ key in any GitHub repo, you instantly get a browser-based VS Code interface without having to clone gigabytes of data locally. It’s perfect for rapid PR reviews, quick documentation edits, or navigating code on the fly without breaking your workflow. Just keep in mind that it runs entirely in the browser sandbox; there’s no compute backend, no terminal, and no code execution.”

For any heavy lifting or actual compiling, he added, the developer will still need the raw compute of a local workstation, or a full cloud environment like Codespaces.

The problem, Askar says, is that this functionality is achieved by github.com POSTing over an OAuth token to github.dev that allows it to interact with GitHub on your behalf. “The token is not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to,” he wrote in the blog.

“The presence of this token, and the fact that this web app is running almost the entire brunt of VSCode’s million line Typescript codebase, makes it a great target for anyone looking into VSCode bugs,” he wrote.

The exploit

Askar said that a threat actor could install an extension in a repository using a Jupyter notebook, a web application for creating and sharing computational documents that has the ability to install a malicious local workspace extension while skipping the publisher trust check. In his proof of concept, Askar said that once his payload runs, the newly installed extension will grab the GitHub API token, run a query to get the private repos the developer has access to, and then print out the replies and the token.

This vulnerability also exists in the desktop version of VSCode, Askar said, though it’s harder to exploit, since a threat actor would need to convince the victim to clone their repo and open the notebook containing the webview script payload. “Of course,” he added, “if you [the hacker] had some other XSS [cross-site scripting attack] in a webview that you can get a victim to open, you get effectively full RCE [remote code execution] on their computer.”

In an email, he said this vulnerability was “about as serious as it gets. Any website on the internet could have redirected you to a github.dev link that could have provided an attacker a token to read and modify your code repos. If one could convince the maintainer of a popular software project to click a link, they could have made whatever modifications they wanted to their project.”

This means, said Enderle, “we have to start treating developer endpoints with strict, isolated, zero-trust parameters, because we clearly cannot rely on vendor complacency to protect us.”

This issue reinforces the point that you should never follow any links unless you know exactly where they will take you, added Dwayne McDaniel, principal developer advocate at GitGuardian.

Short notice

Here’s where things get complicated. Because of an unhappy experience when disclosing a previous VSCode vulnerability to Microsoft — the bug was fixed, but Askar wasn’t given credit — this time he only gave GitHub one hour notice that this new discovery was going to be published. Microsoft applied what Askar calls a “stopgap” fix by adding a confirmation when a developer opens notebooks in web VSCode, and by not allowing the trusted publisher requirement to be skipped by commands.

[Related content: When responsible disclosure becomes unpaid labor]

An ethical question

Askar’s short notice raises an ethical question: How far in advance should a responsible researcher give notice to a vendor about a vulnerability before publicly revealing it?

These days, most infosec pros agree that notice must be given, or else a threat actor can quickly exploit a hole. Not only that, but the researcher risks damage to their reputation if reasonable notice isn’t given. Experienced researchers often give vendors at least 30 days to create and distribute a patch.

For their part, vendors often create bug bounty programs, or partner with bug bounty programs, to reward researchers for their work. Unfortunately, some vendors don’t always credit researchers, or downplay the damage a vulnerability can cause. In fact, last month Microsoft and a prominent cybersecurity researcher got into a public spat about one such alleged incident.

An imbalance of power

Asked for comment about Askar’s most recent discovery, a Microsoft spokesperson said, “we value the critical role that the security research community plays in strengthening the security of our products, services, and the broader technology ecosystem. While independent researchers determine when and how to publish their findings, we remain committed to rapidly assessing reported issues, mobilizing the appropriate engineering and security response resources, and delivering mitigations, guidance, and protections as quickly as possible to help safeguard our customers.”

The spokesperson added that the issue Askar reported “has been mitigated for our services and no customer action is required.”

[Related content: Is the vulnerability disclosure process glitched?]

There is a balance between coordinating disclosure with a software vendor (CVD) and full disclosure, Askar told us. But, he added, there’s an imbalance of power. “A security researcher can pour countless hours into an issue, ensuring they develop a good proof of concept and provide all the steps to recreate the issue. With this, they hope to at least get an acknowledgement for their efforts, which they can use to further their security track record or, in the best case, a monetary bounty reward.”

However, he added, “If security vendors don’t adhere to their side of the bargain, public disclosure is one of the few options security researchers have (if they don’t want to sit on their vulnerabilities or sell them on the black market). It forces the vendor to acknowledge the security issue publicly and usually leads to a much faster resolution than any private communication would.”

This, said Enderle, creates problems for enterprises: “When vendor bureaucracy penalizes responsible disclosure, it alienates the security community and forces public zero-day drops, ultimately leaving enterprise customers holding the bag.”