Rene from Casco here. While our agents were performing a security test, they discovered a database takeover vulnerability. It's a good example of how SQL injection is still a test path that needs to be explicitly be validated. Really want to give props to the ElectricSQL team from issue reported to issue fixed and deployed, it took ~2 hours.

Thanks from the Electric side to the Casco team for the responsible disclosure, comprehensive repro and great communication through the process.

This was a critical one to identify and patch: https://github.com/electric-sql/electric/security/advisories...

Just to repeat for visibility, if you're self-hosting the Electric sync service, upgrade to version >= 1.5.0 immediately.

Author here. We were analyzing a compromised contributor account targeting better-auth when we noticed something interesting about the attack vector. Most coverage of supply chain attacks focuses on the "what happened" but I wanted to document the "how it actually works" with the deobfuscated code.

Wwo things stood out: 1. hiding the payload in next.config.mjs is clever because GitHub's UI truncates long lines so the malicious string is literally invisible when scrolling through the file. second, storing the c2 payload on binance smart chain means theres no server to take down. The axios attack was mitigated by removing the GitHub-hosted payload. This one can't be.

2. found 30+ repos with the same signature string. Pretty sure there's way more we didn't catch with basic string matching.

happy to answer questions about the deobfuscation process or the c2 protocol analysis.

Your website fingerprints devices so hard it throws a warning after rendering content.

are you using Safari's Lockdown Mode?

What if they are? Why should people attempting to browse securely be punished?

Just debugging the issue :-)

> GitHub's UI truncates long lines so the malicious string is literally invisible when scrolling through the file.

It looks like the screen recording was made on a Mac. Does your browser (Chrome?) respect the OS-wide ‘Always show scroll bars’ setting?

After all, it’s not that GitHub is “truncating” the lines, it’s that scroll bars aren’t visible - so it’s not immediately obvious that there’s code outside of the viewport.

> it’s that scroll bars aren’t visible

well truncating or not, that seems to be a major security UI issue...?

Do you see this project merge with the Chonkie at some point? Or do you intend to keep it separate?

Memchunk is already in Chonkie as the `FastChunker`

To install: pip install chonkie[fast]

``` from chonkie import FastChunker

chunker = FastChunker(chunk_size=4096) chunks = chunker(huge_document) ```

How does it deal with loops? I’ve often see workflow builders struggle at that?

for loops we use two sentinel nodes with a backwards edge, and before each iteration, we check the condition and update loop variables.

  sentinel -> body -> sentinel (condition with backwards edge to first sentinel)

in the UI, this is just represented as another block, and depending on the varying types of loops you can either define a collection or the number of iterations

and specifically nested loops. if you're spinning up full runtime copies for each loop, you're gonna have a hard time

at the moment, we don't support 'loops in loops' on the client-side, but not for any other reason asides from it becoming confusing for users. since we don't actually make copies for each loop, it wouldn't be a performance issue.

I actually wonder is there a way to feed back some consistently reedited code into the context window of your coding agent tools, so that future edits require less tokens?

Interesting idea. We are exploring a Git AI MCP now. Hopefully a lot of this data can raise the agent’s IQ a few points.

Hi Rene from Casco here. I think the post just referenced us as a customer because we use it for pentesting. For us, Prism solves the "browser agents can reliably auth into any website" problem.

Hi - Rene from Casco here. Thought to share a bit about our journey of dealing with auth for browser agents before Prism. We have a diverse set of customers whose login experience differ dramatically. Sometimes it's directly accessible on request, other times, you have to click through into a "login menu", other times we'd be dealing with Google sign-in and OTP.

We initially tried manually uploading session cookies to our browser agent after we authenticate locally. But soon realized how unscalable that is. We needed a general purpose API that allows our agents to auth into any application reliably. We needed something like Prism because making an agent reliable for our vertical is hard enough and I don't want us to maintain infrastructure just for the purposes of managing test user credentials and session management. If you're using browser agents and they've "hit the auth wall", then you know what I'm talking about.

Thanks for building Prism for us and letting us be a pilot customer. The API is straightforward and a pleasure to use. Can't wait for user sign-up and GitHub auth support to come soon.

It's a pleasure to work with you. Excited to expand to more login cases and support login to more websites.

wait, it's completely free during the preview period? That's a better deal than Cursor, Windsurf, or Claude Code. Gotta check it out

How does this scale horizontally across multiple regions. Is this something on your roadmap?

It’s definitely on our roadmap, but not a priority because no one using us needs it. Is this something that would be useful to you?

Pretty cool stuff. How does it deal with self-hosted data sources? can it run inside a VPC and talk to my RDS instances directly?

You can self-host Airweave on Docker or Kubernetes within your VPC. We eventually want to move towards AWS/Azure/GCP marketplace offerings that should make this easier for you. RDS should work - if you get an instance with PSQL/MySQL dialect.