> Responsible Disclosure GitLost was responsibly disclosed to GitHub. Vulnerability details are shared here with their knowledge.

Why does this section not have when it was fixed or GitHub acknowledge/rejected this?

Did they not fix this?

▲

Gigachad 7 hours ago | parent | next [-]

This isn’t a normal software bug, it’s not fixable in the same way you can’t fix regular support staff from being tricked.

The answer is you should not allow LLMs access to untrusted input and sensitive data at the same time.

▲

valleyer 7 hours ago | parent [-]

Your second paragraph directly contradicts the first.

▲

antonvs 29 minutes ago | parent | next [-]

The point is that Github can’t fix it. It’s the user’s responsibility to not grant access to accounts that shouldn’t have access to the resources in question.

▲

LoganDark 6 hours ago | parent | prev [-]

Since you cannot fix information leakage from LLMs, you must remove the information so that it cannot be leaked. There is no contradiction there.

▲

valleyer 6 hours ago | parent | next [-]

Right, that's the fix. So saying that it's not fixable is incorrect.

▲

3 hours ago | parent | next [-]

[deleted]

▲

Gigachad 5 hours ago | parent | prev | next [-]

The LLM is not fixable. Deleting the LLM or crippling it to the point of being useless isn't fixing the bug.

	▲	Austiiiiii 29 minutes ago \| parent \| next [-]
		This is some very weirdly loaded language for a discussion about security. Applying the same RBAC controls that should be restricting all human requests in a system is not "crippling ... to the point of being useless." There isn't a world where granting a layer of the stack the ability to bypass hardcoded security limitations is a value add.
	▲	crote 2 hours ago \| parent \| prev [-]
		Why not? If Ford puts a button in their car which blows it up when you press it, removing the button fixes the issue. If your LLM implementation is fundamentally insecure, you'll have a giant gaping security hole until you remove your LLM implementation. The alternative is arguing that having the LLM is worth routinely leaking all your code and secrets and occasionally giving complete strangers full access over your repos. Somehow, I think that's going to be a hard sell.

▲

antonvs 27 minutes ago | parent | prev | next [-]

It’s not fixable by GitHub, which is what the original comment was asking about.

▲

6 hours ago | parent | prev [-]

[deleted]

▲

rileymat2 6 hours ago | parent | prev [-]

There is a major contradiction depending on the definition of “support staff” and the role of the llm in the system which may need access to sensitive data or systems to perform its functions.

▲

dzikimarian 7 hours ago | parent | prev | next [-]

Fix what? They setup LLM with access to private data and ability to read public comments. That's simply misconfiguration.

▲

wzdd 5 hours ago | parent [-]

The OP notes that they had to use special phrasing to get their exfil to work, so clearly GitHub was aware of the issue and made an attempt to prevent it.

It seems like the proper fix is for GitHub not to allow their agentic workflow to execute in a public repo context if it also has private repo access. Or, to use your phrasing, for GitHub to flag and disallow this easily-detectable and dangerous type of misconfiguration.

	▲	brookst 2 hours ago \| parent [-]
		This “detectable and dangerous type of misconfiguration” is used by many developed daily and breaking it would break important workflows. It’s like saying that an OS should enforce that home directories can only have 0600 permissions. Yes, it prevents accidentally configuring world readable on files, but there are legit reasons for wanting to share a file from your home dir.

▲

jofzar 4 hours ago | parent | prev [-]

Actually op, can you clarify if you did this with the below setting on? There is a literal setting to stop this so I'm curious if this was created because of this report or if this is just negligence from the reporter to not add this as a comment.

https://github.github.com/gh-aw/reference/cross-repository/#...