PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking

Transcript

PeopleSoft gets hit by a zero-day. npm changes

what code is allowed to run during install. GitHub

removes long-lived personal access tokens from

agentic workflows. And Anthropic reminds everyone

that your AI dependency can disappear for reasons

that have nothing to do with uptime. The theme

this week is simple. Default trust is getting

punished. Old enterprise systems were trusted.

because they were internal. Package installs

were trusted because that is just how the ecosystem

worked. CI/CD tokens were trusted because they

were convenient. AI models were trusted because

the API worked yesterday. But production does

not care why you trusted something. It only cares

what that trust was allowed to do. I'm Brian

Teller from Teller's Tech, and this is Ship It

Weekly. Welcome back to Ship It Weekly, the show

where we look at the DevOps, SRE, cloud, platform,

and security stories that actually matter when

you are the person who eventually has to keep

the thing running. This week is about default

trust. We're starting with Oracle PeopleSoft

and a zero-day that was reportedly exploited

before Oracle released an emergency patch. Then

we'll talk npm v12. changing install-script

defaults which is great for supply-chain security

and maybe a little annoying for some CI pipelines

after that we'll get into github agentic workflows

no longer needing personal access tokens which

is the kind of boring credential change that

actually matters then we'll talk about Anthropic

disabling fable 5 and mythos 5 after a us export

control directive because AI model availability

is now also a policy-risk dependency. In the

lightning round, we'll hit Tekton CloudEvents

moving to a dedicated events controller, NVIDIA

Triton 26.04 changing inference server defaults,

AWS Nitro Isolation Engine using formal verification,

and Homebrew 6.0 requiring explicit trust for

third-party taps. The human closer this week

is about trust defaults, because a lot of incidents

start with one quiet assumption. The system is

internal. The package is fine. This token is

safe. This model will be there tomorrow. And

sometimes that assumption is the real production

dependency. So let's get into it. Oracle issued

an emergency advisory for CVE-2026-35273 in

PeopleSoft PeopleTools. And yes, I know, PeopleSoft

does not sound like the kind of shiny cloud-native

story that makes people sprint to the podcast

app. But that is exactly why it matters. A lot

of modern companies still depend on older enterprise

systems for HR, finance, payroll, student records,

supply-chain. and all the boring data that becomes

extremely exciting when attackers get it. Oracle

says that the vulnerability is remotely exploitable

without authentication and can result in remote

code execution. Public reporting says exploitation

was observed before Oracle's emergency advisory,

with ShinyHunters linked activity targeting

mostly U.S. organizations, especially higher

education. So the shape of the story is pretty

clear. Old enterprise application, sensitive

data, remote unauthenticated exploit, active

exploitation, emergency patch. That is a bad

combination. And the lesson for DevOps, SRE,

platform, and cloud teams is not just patch PeopleSoft.

Although, yes, obviously, patch PeopleSoft. The

bigger lesson... is that the enterprise app tier

is still part of your perimeter, even if everyone

emotionally moved on to Kubernetes. A lot of

teams have a weird relationship with older enterprise

platforms. They are important enough that nobody

can turn them off, but old enough that nobody

really wants to own them. They live in a special

network zone. They have a special upgrade window.

They have special vendor requirements. They have

special firewall rules. from 2017 that everyone

is afraid to touch. And somehow, because they

are enterprise apps, people stop thinking of

them like internet-exposed production systems.

Attackers do not care what generation of architecture

the system belongs to. They care whether it has

data, access, and a path in. PeopleSoft may not

be the cool part of your stack, but if it holds

HR data, finance data, student data, employee

data, or business workflow data, it is very much

part of your attack surface. This is also a good

reminder that legacy does not mean low-priority.

Sometimes legacy means high-value, hard-to-patch,

badly isolated, and full of data. That is not

low-priority. That is where an attacker brings

a shovel. The practical takeaway is simple. Know

where these systems are. Know whether they are

internet exposed. Know who owns patching. Know

who owns logs. Know what normal access looks

like. Know whether unusual agents, web shells,

or scheduled tasks would actually be noticed.

And if you are a platform or cloud team that

thinks this is someone else's problem, be careful.

Because during the incident call, someone else's

problem has a funny way of becoming why did nobody

know this existed. Your ERP systems, HR systems,

finance systems, and admin portals are production

systems. Treat them that way. Second story. npm

v12 is changing some defaults around install

scripts. And this one matters to developers,

platform teams, CI maintainers, security teams,

and anyone who has ever watched an npm install

do 12 things they did not explicitly ask it to

do. GitHub says npm v12 is expected in

July 2026. And one of the big breaking changes

is that allowScripts will default to off. That

means npm install will no longer execute pre

-install, install, or postinstall-scripts from

dependencies unless they are explicitly allowed.

Prepare scripts from git, file, and link dependencies

are blocked the same way. These settings are

already available in npm 11.16.0 for migration

testing. This is a big ecosystem shift. For years,

npm install has been more powerful than people

like to admit. You run the package install. The

package runs code. That code might build native

bindings, download binaries, generate files.

patch something, bootstrap something, do the

magic that makes everything work. But that same

install-time execution path is also a supply

chain attack surface. A malicious package does

not need your app to import it at runtime if

it can run code during install. It only needs

to land in the dependency tree. Then the CI runner,

developer laptop, or build machine does the rest.

This is why this change matters. It moves the

ecosystem from implicit trust towards explicit

trust. And yes, that is good. But some builds

are going to break. Because a lot of pipelines

have been relying on install-time magic without

documenting it. Native modules. Post install

downloads. Git dependencies. File dependencies.

Link dependencies. Internal packages. Packages

that compile. Packages that generate code. Packages

that do one tiny little install step that nobody

has looked at since the person who wrote it left

the company. Those assumptions are about to become

visible. And visibility is great. Right after

it ruins your Tuesday. The practical takeaway

is not panic about npm v12. The takeaway

is to test early. Run builds with the new behavior

before it becomes the default. Find which dependencies

need scripts. Decide which scripts you actually

trust. Document why. And do not just flip everything

back on because one pipeline failed. That defeats

the point. This is a chance to clean up dependency

trust, especially in CI. Ask what install-scripts

run today. Ask whether CI runners have secrets

available during install. Ask whether build steps

can reach internal services. Ask whether developers

are running installs on machines with cloud credentials,

SSH keys, or package publishing rights. Because

the blast radius of an install-script is not

just the package. It is whatever the install

environment can access. I like this change. It

is going to annoy people, but sometimes the annoying

default is the correct default. npm install is

finally getting less magical. And that means

that some teams are about to discover how much

magic they were depending on. Third story. GitHub

says agentic workflows no longer need a personal

access token. And yes, that sounds boring. But

boring credential changes are often the ones

that save you later. Previously, agentic workflows

needed personal access tokens in certain setups.

Now GitHub says, These workflows can use the

built-in GITHUB_TOKEN and the copilot

request write permission instead. The point is

to avoid creating and storing long-lived personal

access tokens for agentic workflows. This matters

because agentic CI/CD is already risky enough.

These workflows can read context, generate changes,

open pull requests, review code, call tools,

interact with repo state, and eventually, in

some environments, they may become part of release,

remediation, triage, or automation paths. So

the credentials they use matter a lot. A personal

access token is often tied to a person. It may

be long-lived. It may have broad permissions.

It may sit in secrets. It may get copied between

repos. It may survive longer than anyone intended.

It may still exist after the workflow changed,

the person changed teams, or everyone forgot.

why the token was created. That is not a great

pattern for agentic automation. A scoped workflow

token is not magic. You still have to configure

it correctly. You still have to review permissions.

You still have to think about which events can

trigger the workflow. You still have to worry

about untrusted input. But it is a better default

than handing an agent a long-lived personal

credential and hoping everyone remembers where

it lives. The platform takeaway is simple. If

you are experimenting with agentic workflows

in GitHub, review the whole trust model. What

repos can run it? What events can trigger them?

What permissions do they get? Can pull request

content influence the agent? Can issue comments

influence the agent? Can the agent write code?

Can it approve changes? Can it call external

tools? Can it see secrets? Can it publish artifacts?

Can it affect production? And are you still using

personal access tokens where you do not need

them? Because agents are not just assistants

once they enter CI/CD. They become automation

services. And automation surfaces need boring,

strict, reviewable credentials. So yes, use the

better GitHub auth model. But do not stop there.

If it can change code, trigger work, or spend

money, it belongs in your production automation

threat model. Fourth story. Anthropic published

a statement saying that the U.S. government

issued an export-control directive requiring

Anthropic to suspend access to Fable 5 and Mythos

5 by any foreign national, whether inside or

outside the United States, including foreign

national Anthropic employees. Anthropic said

that the net effect was that it had to abruptly

disable Fable 5 and Mythos 5 for all customers.

to ensure compliance. Access to other Anthropic

models was not affected. Now, this is not a normal

SRE outage. There was not a regional failure.

There was not a bad deploy. There was not a database

incident. There was not a capacity problem. But

for customers who depend on those models, the

effect is still operational. The dependency disappeared.

and it disappeared for policy reasons. That is

the lesson. If AI APIs are part of your production

path, dependency risk is no longer just uptime,

latency, quota, and cost. It is also model availability,

geography, export-controls, regulatory shifts,

vendor policy, safety policy, commercial access,

model deprecation, compliance interpretation,

and whatever new category we invent next quarter.

This is uncomfortable because AI dependencies

can be harder to substitute than people pretend.

You can usually swap one HTTP endpoint for another

at a code level. But can you swap the behavior,

the context window, the latency, the tool calling

behavior, the moderation behavior, the cost profile,

the prompt format, the eval results, the customer

experience, the internal workflow? The fallback

may not be use a different model. The fallback

may be a degraded mode, a smaller model, a cached

response, a human review queue, a simpler workflow,

a feature flag, a regional restriction, or a

message that says this capability is temporarily

unavailable. Boring fallback behavior is better

than waking up to discover your product path

depends on a model that is no longer available

to you. The practical takeaway is to add AI models

to your dependency register like any other production

dependency. Track which features use which model.

Track whether the model is in a critical path.

Track where your users are. Track fallback options.

Track whether you can degrade gracefully. Track

whether a vendor-side access change would be

an incident. And test the fallback. Do not just

write... Fall back to another model in a doc

and call it done. Actually try it. Because the

weird thing about AI infrastructure is that even

when the API shape looks portable, the behavior

is not. Your AI dependency can disappear for

reasons that have nothing to do with uptime.

That means your reliability plan needs to cover

more than outages. Now let's do a quick lightning

round. First, Tekton pipelines changed how cloud

events are sent. Cloud events for PipelineRuns

and TaskRuns now move through a dedicated Tekton

events controller instead of the core pipeline

run and task run controllers. That means operators

need to make sure the tekton-events-controller

deployment is actually running. Small looking

platform changes like this can have real operational

impact. If CI/CD observability, event routing,

notifications, or automation depends on Tekton

events, make sure the new controller is deployed,

monitored, and part of the upgrade checklist.

Because the pipeline ran, but the event never

showed up, is exactly the kind of thing that

sends teams into Slack archaeology. Second, NVIDIA

Triton Inference Server 26.04 has changes operators

should read before upgrading. Client shared memory

is now disabled by default and must be enabled

explicitly if you rely on the old behavior. Triton

also enforces max inflight requests as a shared

limit across ensemble requests, which is meant

to prevent unbounded queue growth in ensemble

pipelines. The short version is this. AI inference

servers are now normal platform infrastructure.

Defaults change. queue behavior changes, memory

behavior changes, model control changes. So upgrade

them like production systems, not sidecar experiments.

Third, AWS published a deep dive on the Nitro

Isolation Engine. AWS says the Nitro Isolation

Engine is generally available on Graviton5-based

instances and uses formal verification to demonstrate

isolation properties. That is interesting because

cloud isolation is usually something customers

trust, but cannot directly inspect. Formal verification

does not mean bugs are impossible, but it does

show where cloud providers are heading. Smaller

trusted components, tighter isolation boundaries,

and mathematically checked properties for the

parts that protect customer workloads. Fourth,

Homebrew 6.0 introduced tap trust. Homebrew

now requires explicit trust. for third-party

taps before evaluating or running their Ruby

code, while official taps remain trusted by default.

This is another supply-chain default, changing

from sure, run it, to are you sure you trust

this? And that is good. A third-party tap can

contain arbitrary Ruby. If your developer laptops,

CI runners, or bootstrap scripts use Homebrew,

This change is worth knowing about. Some installs

may prompt or fail until trust is explicit. That

might annoy people. But again, that is the point.

Developer tooling is part of the supply-chain.

And fewer things should get to run code just

because they were convenient. The human closer

this week is about default trust. PeopleSoft

was trusted because it was an enterprise system

that had been around forever. npm install was

trusted because package managers have always

done some magic. agentic workflows were trusted

with personal tokens because that was the easy

path. AI models were trusted because the API

was available yesterday. Tekton events were trusted

to keep flowing. Triton defaults were trusted

until they changed. Cloud isolation was trusted

because that is the cloud model. Homebrew taps

were trusted because developer tooling has historically

been pretty casual about running code. Different

stories, same pattern. Production risk often

hides inside the trust defaults nobody has revisited.

The system is internal. The install-script is

normal. The token is convenient. The model will

be available. the event will fire the tap is

probably fine those assumptions may be true until

they are not so the practical question this week

is simple what are you trusting by default which

enterprise apps are still exposed which package

installs run code in ci which agents still use

long-lived tokens which ai models sit in production

paths which developer tools can execute code

before anyone reviews it that is platform work

now not just building the shiny new thing but

revisiting the old trust assumptions before attackers

vendors regulators or outages revisit them for

you find the defaults then decide whether they

still deserve your trust That's it for this week

of Ship It Weekly. We covered the Oracle PeopleSoft

zero-day, npm v12 install-script changes,

GitHub agentic workflows moving away from personal

access tokens, Anthropic's Fable and Mythos model

suspension, and a lightning round on Tekton,

NVIDIA Triton, AWS Nitro Isolation Engine, and

Homebrew 6.0 tap trust. If this episode was

useful, follow or subscribe wherever you are

watching or listening. If you are on YouTube,

hit subscribe. If you're in a podcast app, follow

the show there. And if you know someone dealing

with enterprise app security, CI/CD supply-chain

risk, agentic workflows, AI dependency planning,

or developer tool trust, send this one to them.

It helps the show grow, and it helps me keep

making this kind of content for people who actually

live with these systems. You can find the weekly

brief at OnCallBrief.com, and more episodes

and show notes at shipitweekly.fm. I'm Brian

Teller from Teller's Tech. Thanks for listening.

And remember, production does not care why you

trusted the default. It only cares what that

default was allowed to do.

PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

More from Ship It Weekly

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

Get the next episode in your inbox

PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

Related On Call Brief

More from Ship It Weekly

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

Get the next episode in your inbox