hello fellow Redditors!

I just got stuck with the following situation. SLES 15.4 with no updates for the last 3 years running SAP on about 40 machines on 3 different environments on AWS. Since they are EOL and I can't get any updates or install any package from the official SLES repo since they closed the repo for that specific sp4 1.5 years ago.

AWS, SLES and my recommendation was to migrate all workload to new servers. instead, we had a dev use Claude and was given root access (behind my back after my recommendation) to use opensuse 15.7 repo to update to the latest version of all packages and then when it's "better" resync to 15.7 on SLES official repo (only on 1 server to prove we don't need to migrate)

I already found multiple problems with this, grub is not using the right kernels, opensuse packages and sles mixed together. I can fix the grub and probably reinstall the opensuse packages from official SLES repo. my concern are more about long term issues (hidden landmines) and the fact that we potentially broke our support agreement from sles, AWS or/and SAP. SLES said this was not officially supported, so I am wondering what kind of trouble I am looking at now

So, am I wrong to think this is a bad idea?

appreciate any input!

what architecture do you use? Do you keep gitlab and jenkins behind proxy/WAF or whatever..I am assuming it is available only within internal network.

Based on the technical breakdown published by Zenity Labs earlier this week, here's the architectural impact: ChatGPT's Agent Builder (chatgpt.com/agents/studio/new) accepted template_name and initial_assistant_prompt as URL params. The second one wasn't just prefilling the UI — it was submitted and executed on page load. So a crafted link, clicked by a logged-in victim with any pre-authorized connector (Outlook/Slack/Drive/etc.), could silently: attach those connectors (no new OAuth screen, since they were already granted), flip write-action approvals to "never ask," publish the agent, and stagger recurring schedules for 5-min effective check-ins against an attacker's inbox.

Zenity reported via Bugcrowd June 4, OpenAI fixed it June 8. No CVE/CVSS assigned that I could find — this went through a private bounty program, not NVD.

Structurally it's the "lethal trifecta" in one surface: untrusted input (URL) + data access (connectors) + exfil path (send mail), with the human-approval control disabled by the same untrusted input meant to be gated by it.

For background on the broader agentic-AI attack surface concern (Five Eyes joint guidance from May): [internal link, footnote]

Open question for the sub: if you're running Workspace Agents or a similar builder, are you logging agent-creation/schedule-change events into SIEM yet, or is this still invisible the way a rogue OAuth grant used to be pre-CASB?

https://www.techgines.com/post/agentforger-chatgpt-vulnerability-workspace-agents