securesaml

Nice find. The tokens being leaked in actions log was not one of the security implications I thought of when they released the feature.

How many other actions/libraries do you think are vulnerable?

It's limited to ghs_ (server to server token's), that have the new format enabled: https://github.blog/changelog/2026-04-24-notice-about-upcomi... (and actions that use the vulnerable package)

This include's the GITHUB_TOKEN that is builtin within a actions jobs.

Github enterprise cloud is on github.com and with more features: http://github.com/account/enterprises/new

They don't host github enterprise server for you (though gitlab has something called gitlab dedicated which they host gitlab ee for you).

there's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data?

it is less of a problem for revoking attacker's keys (but maybe it has access to victim's contents?).

agreed it shouldn't be used to revoke non-malicious/your own keys

I wouldn’t recommend this. What if GitHub’s token scanning service went down. Ideally GitHub should expose an universal token revocation endpoint. Alternatively do this in a private repo and enable token revocation (if it exists)

I'm not too sure about the root cause about tj-actions. IIRC there are some libraries that compromised by actions injections vulnerabilities, where a security specialist could have helped.

I have seen small utility libraries like tj-actions get compromised because there aren't any security specialists looking at the library.

My main concern is supply chain compromise.

The problem is lots of open source is unmaintained/insecure, and there aren't any security engineers on those open source libraries.

For the library to be secure, there needs to be funding, not by magic and expecting maintainers will do stuff on there free will.

Correct, maintainers can say that and get shamed.

And it leads to unmaintained libraries, since companies don't want to pay.

At some point, is open sourcing your work a liability?

The problem is more so maintenance.

The expectation of FOSS is that the users and maintainer work together to resolve bug fixes/features/security issues.

However many companies will dump these issues to the maintainer and take it for granted when they are resolved.

It's not a sustainable model, and will lead to burnout/unmaintained libraries.

If the companies don't have the engineering resources/specialization to complete bug fixes/features, they should sponsor the maintainers.

Google has a program where you can submit patches to OSS projects (including libxslt) https://bughunters.google.com/about/rules/open-source/492808...

The patches need to fix a systemtic design flaw (which seems like you are trying to do).

You are eligible even if you are a contributor:

> Q: I'm a core developer working on one of the in-scope projects. Do my own patches qualify?

> A: They most certainly do.

Additionally, github has: https://resources.github.com/github-secure-open-source-fund/

Companies have changed after seeing the log4j incident and are open to funding open source security (but we still need more)

I agree MSFT should have paid way more.

My point is if that FFmpeg, tried to raise more awareness of the issue, say talk to news outlets, they could get much more funding from MSFT.

Furthermore, big companies like Google, Microsoft care a lot about security. So they could raise money for security engineering like fixing memory corruption issues. Of course, FFmpeg could complain Google, Microsft doesn't care about all the high severity vulnerabilities in FFmpeg. That would be much more of an eye catcher.

It's usually the more user-facing products that can thrive on this freemium model (probably full web apps or a lot of code). For example, laravel might get a lot of funding from this.

However, the underlying infrastructure libraries, will not get any funding from this, even though they have much more users. For example, libxml2, xzutils, http parser ...

You can't build any product off of an infrastructure library, purchasing support doesn't make sense, and there are little bonus features to be made.

One way to remedy this, is to have well funded open source projects take ownership of its dependencies.

https://news.ycombinator.com/item?id=39912916 they did get some funding after asking.

> Companies say "This my code when I need it, and it's your code when it breaks", and developers read the fine print very late, because they thought exposure is valuable.

I think that this is an accurate description of working relationship. But, the fine print (MIT license) explicitly says that the companies are responsible:

> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED

I agree that open source infrastructure needs to be funded. I think first there needs to be a mindset shift in who's responsible for open source.

Currently when new vulnerabilities pop up (i.e. xz-utils compromise, log4j shell), people are quick to blame the maintainers for it. Why shouldn't companies instead be responsible for these vulnerabilities?

Currently, companies treat open source code as someone else's, so they don't bother to audit, maintain it, or fund it. Clearly, this is wrong, and reflected in the oss license, which states that code is solely consumer's responsibility.

sure. But companies believe that open source developers owe everything to the them (i.e. fixing bugs, contributing to feature requests, critical security releases ...).

For me, I don't think that the application is public exposed is really the problem (i.e. not in intranet).

I think the real problem is that these applications (Entra ID) are multi-tenant, rather than a dedicated single-tenant instance.

Here, we have critical identity information that is being stored and shared in the same database with other tenants (malicious attackers). This makes multi-tenancy violations common. Even if Entra ID had a robust mechanism to perform tenancy checks i.e. object belongs to some tenant, there are still vulnerabilities. For example, as you saw in the blog post, multi-tenant requests (requests that span >= 2 tenants), are fundamentally difficult to authorize. A single mistake, can lead to complete compromise.

Compare this to a single tenant app. First, the attacker would need to be authenticated as an user within your tenant. This makes pre-auth attacks more difficult.

I am working on an SAML Attacker (that basically tests web apps against all known SAML exploits). It includes all the test cases.

I can share you the repository if you want to integrate it in RubySAML (or any other library). Email me [alex]@[securesaml.com] (without the [ ])

Issue is not with go's parser, but instead about processing layer using different input than verifying layer [1]

We patched the gosaml2 (and other go saml libraries), by ensuring only the authenticated bytes are processed (not the original XML document). You can see the patches here: https://github.com/russellhaering/goxmldsig/commit/e1c8a5b89... https://github.com/russellhaering/gosaml2/commit/99574489327...

> I just wrote my own for my SAML.

Curious to see your implementation for SAML and XML Signatures.

[1]: https://bsky.app/profile/filippo.abyssdomain.expert/post/3le...

The correct conclusion is: https://news.ycombinator.com/item?id=44337330

The problem of trying to ensure that each parser behaves the same for all input is twofold: - JSON and XML specifications are complex, lots of quirks. So not feasible. - Does not solve the fundamental issue of the processing layer not using the same data that is verified in the verification layer.

Note: the processing layer parses the original input bytes, while the verification layer verifies a struct that is parsed using another parser.

Processed: Proc(input) Verified: VerifyingParser(input)

See: https://bsky.app/profile/filippo.abyssdomain.expert/post/3le... that was about a signature wrapping attack in crypto, but it also applies here.

This is correct. In blog post they say: > Other examples exist, but most follow the same pattern: the component that does security checks and the component that performs the actions differ in their view of the input data.

This would be solved (as you described), by ensuring that the downstream layer uses only contents that are verified in the security check layer.

If they are using a microservice then: Security check API -> return verified data (i.e. re-serialize the verified JSON or XML into byte form, NOT the original input) -> Processing layer i.e. userCreate API uses verified data.

This is the method we used in fixing the ruby-saml example.

See: https://bsky.app/profile/filippo.abyssdomain.expert/post/3le...

Agree that XML signatures is terrible. The main problem with XML signatures (and many message signatures) is that it makes it impossible to know which bytes are cryptographically authenticated.

For example, most libraries do something like: ``` valid = validate_xml_signature(xml_message, key) if valid: parse(xml_message) # note xml_message was not crytographically authenticated ```

It should be: ``` verified_bytes = validate_xml_signature(xml_message, key) def validate_xml_signature(message, key): signed_bytes, authenticated_tag = parse_signature(message) # cryptographic proof of signed_bytes if key.verify(signed_bytes, authenticated_tag): return signed_bytes

parse(verified_bytes) # parse into whatever you want i.e. SAML Assertion ```

Now this method is foolproof as you only use authenticated data. This is a rough description of how formal verification would apply to XML Signatures. Of course it wouldn't prevent processing vulnerabilities, say XML parsing (XXE) or XML signatures transforms (XSLT) which has its own set of footguns. Or vulnerabilities inside cryptographic primitives.

You do mention that companies should switch to something like OIDC/OAuth. Many large companies just don't have the resources to start switching when the current system just works, say a old company in healthcare. So they are stuck with a bad standard like SAML or XML signatures.

That's why I am securing libraries like ruby-saml to ensure that there are no more XML signature vulnerabilities. During the patch for ruby-saml, we redesigned the library to ensure that there are no more xml signature vulnerabilities https://github.com/SAML-Toolkits/ruby-saml/commit/e9c1cdbd0f... https://github.com/SAML-Toolkits/ruby-saml/blob/fbbedc978300...

I am trying to apply this to all the other libraries. The problem is that we are not getting funding at all. Ruby-SAML's maintainer never got any new sponsorships, despite asking for it: https://github.com/sponsors/SAML-Toolkits It disincentives any security redesigns like this: it just takes too long, and quite thankless.

If you want to join our efforts, feel free to contact me at secure[@]securesaml[.]com