SageMaker Logged the Git URL. 3.10.0 Is the Pin

AWS security bulletin 2026-134 is dated in the week of October 15. CVE-2026-110248 sits in git_utils.py inside the Amazon SageMaker Python SDK. When a Git clone fails, repository credentials that showed up in subprocess error output are written to CloudWatch Logs without redaction. An authenticated user who can read those logs can read the plaintext. That is a logging bug. It is not a model card.

Impacted: SDK V2 before 2.257.3, V3 before 3.10.0. Fixed in 2.257.3 and 3.10.0. GHSA-g6w4-jvgp-68x2. Credit: Gouri Sankar A. Workaround if you cannot upgrade today: do not put credentials in Git URLs, restrict who can read the SageMaker logs, review failed-clone output, rotate anything that appeared there.

The changelog already recorded the V3 side of this. v3.10.0, 2026-05-01: “Improve subprocess exception handling in git_utils.” Also in that release: CodeArtifact support for requirements.txt installs, an S3 path traversal fix, better code upload paths. The bulletin is October. The V3 pin is May. Do not write this up as a bug that shipped this week. Write it up as a pin you may still have missed.

We already treated Langflow 1.12.3 as 25 CVEs on a canvas, Studio reading config.json as trust_remote_code, and uv 0.12.18 as a wheel path. This week the secret is in the clone URL.

The failure path is the product

SageMaker jobs clone training code. People still pass https://user:[email protected]/org/repo.git because it works in a notebook. When the clone fails, git writes the URL into stderr. git_utils.py used to let that stderr become a log line. CloudWatch keeps log lines. IAM keeps who can read them. The CVE is the sentence that connects those four facts.

“Authenticated remote user with access to those logs” is AWS’s attacker. That is not the internet. That is someone with logs:GetLogEvents on the job’s group, or a broader CloudWatch role that was supposed to be for debugging. Debug roles are how these bugs become incidents. If your data-science IAM can read every training log in the account, the token in a failed clone is their token now.

Do not put the token in the URL. That workaround is older than this CVE. Deploy keys, GitHub Apps, CodeCommit credentials in Secrets Manager, an IAM role that the job already had. The bulletin still has to say it because the URL pattern is still in scripts. If you find one, rotate. The log line may already have shipped to a ticket system that stores CloudWatch samples.

V2 and V3 are both named. Shops that froze on 2.x because V3 dropped Estimator and Predictor still need 2.257.3. Shops that moved to V3 still need 3.10.0 or later. A pip freeze that says sagemaker==3.9.something is the vulnerable line even if you “already migrated.”

May 1 is the changelog. October is the CVE

v3.10.0 on May 1 improved subprocess exception handling in git_utils. That is as close as a public changelog gets to “we stopped leaking stderr.” v3.10.1 on May 7 is unrelated KMS and JumpStart fixes. If you upgraded to 3.10.0 in May, the V3 issue as AWS describes it is already behind you. If you did not, the October bulletin is your page.

Coordinated disclosure explains the calendar. Gouri Sankar A went through the process. AWS published the CVE in October. The code could move first. Your requirements.txt does not care about the process. It cares about the pin.

The same 3.10.0 notes an S3 path traversal fix. That is a second reason to be on that version, and it is not this article. Do not merge the two bugs in a slack message. Path traversal is a different file. This CVE is git stderr.

PyPI’s sagemaker package lists requires_python >= 3.10. V3.0.0 broke Estimator, Model, Predictor, and their subclasses. The migration note is pip install --upgrade sagemaker or stay on 2.x knowingly. Extras exist for train, serve, mlops. If your image installs sagemaker without a pin, you are taking whatever the resolver had that day. Pin 2.257.3 or 3.10.0 as a floor, then read the changelog before you jump major versions.

CloudWatch is not a secret store

Training logs feel like stdout. They are an AWS service with retention, subscriptions, and sometimes a SIEM connector. A failed clone that prints a URL is now in a system that security teams grep for AKIA and not always for github.com tokens. Add the grep. Then stop putting the token in the URL so the grep has less work.

Restrict log access. The workaround is not poetry. It is an IAM change you can make today while pip runs. People who need to debug a failed training job do not need 90 days of every other job. Put the jobs in groups that match teams. If you cannot, you are running one log lake and calling it convenience.

Review failed Git clone logs. AWS says it out loud because rotation only helps if you know the secret was there. Search for git_utils, fatal:, Authentication failed, and your git host. If a line has a password, rotate that password, then the related tokens, then the deploy keys that shared a human.

Forks and internal wrappers are in the bulletin too. If you copied git_utils.py into a house library in 2023, upgrading the SDK will not save you. Diff your fork against 3.10.0. That sentence is how this becomes a two-week project instead of a pin.

Automation jobs are the ones that still clone

This is an automation story because the clone is in the pipeline, not in a person’s laptop. SageMaker Processing, Training, and Pipeline steps that pull from Git on start are the surface. A notebook user who clones by hand into /home/ec2-user is a different mess. The CVE is the SDK path.

If you already moved code onto S3 or CodeArtifact, you may not hit git_utils at all. 3.10.0 added CodeArtifact support for ModelTrainer and FrameworkProcessor requirements.txt installs. That is a supply-chain feature, not a secret-store feature, but it is a way to stop fetching Git during the job. Fewer clones, fewer stderr lines.

Langflow’s week was “the canvas still executes.” This week is “the log still prints.” Same class of mistake: a developer convenience left on in production. The canvas executed user graphs. The logger executed nothing. It just remembered too much.

trust_remote_code was a file that ran. This is a file that spoke. Both belong in the same review: what does a failed job leave behind. Artifacts, images, logs, cloned trees. If the answer includes a token, the job is a secret store.

Subscription filters on CloudWatch can catch github.com and gitlab.com in near real time if you cannot rotate the IAM story this week. That is a bandage. It does not replace 2.257.3. It does mean a failed clone at 2 a.m. can page someone before the token ages into a SIEM that nobody reads. Keep the filter even after you pin. The next wrapper you copy will try the URL trick again.

What to put in requirements.txt Monday

Floor: sagemaker>=2.257.3,<3 if you are on V2, or sagemaker>=3.10.0 if you are on V3. Do not write >=3 without reading the V3 break. Estimator subclasses will not come with you.

Then a grep of internal repos for git_utils, for https:// git URLs with @, and for GitConfig that still takes a username and password. Rotate anything the grep hits. Then look at CloudWatch. Then tell the people with debug roles that failed clones are now a security ticket, not a shrug.

CodeCommit, GitLab, Bitbucket, and a self-hosted Gitea all take the same URL shape. The bulletin names Git, not GitHub. If your clone string has a password, the host does not save you. Rotate the credential on that host. Then delete the string from Parameter Store copies that predate the pin. Secrets Manager rotation is not the same as “we moved the token last year.” Check the current value.

If you cannot upgrade today, AWS’s workaround is the whole patch: no credentials in URLs, tighter logs, review, rotate. That is a valid Tuesday. It is not a valid December. Pins drift. Images get rebuilt from an old lock file. Put the floor in the base image, not in a wiki.

Python 3.10 is already the package’s floor. If a training image is still on 3.9, you have two upgrades. The CVE does not care about your 3.9 freeze. The resolver will.

A notebook that still clones with an embedded token is the teaching copy of this bug. It works until the remote 404s or the branch is renamed. Then git prints the URL. Then the SDK, on an old pin, puts that print in CloudWatch. Then a support engineer pastes the log into a ticket. Then the ticket is visible to a contractor. None of those people needed the token. All of them can have it. Rotate even if you “only used it in dev.” Dev logs are in the same account more often than people admit.

GitHub App installation tokens and short-lived OIDC are the pattern that makes the CVE boring. The job assumes a role. The role checks out the repo. There is no password in argv. There is nothing for stderr to echo except a host name. If your pipeline cannot do that yet, a deploy key in Secrets Manager is the intermediate. The key still must not appear on the git command line.

v3.10.0 also made _PipelineExecution a public class and wired FrameworkProcessor code_location into upload paths. Those are not the CVE. They are why someone might already be on 3.10.0 for features and still not know they patched git_utils. Read the notes. Do not assume a feature upgrade is a security upgrade unless the file is named.

If GHSA-g6w4-jvgp-68x2 renders as a login wall in your browser, the AWS bulletin is the public text. Use it. Do not wait for the advisory HTML. The CVE number, the versions, and the workaround are already on 2026-134.

JumpStart and KMS notes in 3.10.1 are a day later and a different file. If a teammate says “we are on 3.10” ask which patch. 3.10.0 is the git_utils floor. 3.10.1 is the next bugfix train. Either is fine for this CVE. 3.9 is not.

The useful steal from May 1 is that “improve subprocess exception handling” is how a real fix looks in a changelog: boring, file-specific, easy to skip. The useful steal from October 15 is the CVE number you can put in a ticket. Same bug, two dates. Pin the SDK. Read the failed clone. Do not keep the token in the URL just because the notebook accepted it in 2024.