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 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…
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…
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…
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…
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…
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…
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…
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,…
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…
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…
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…
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…
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…
[dead]
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 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…
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…
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…
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…
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…
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…
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…
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,…
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…
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…
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…
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…
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…
[dead]