Unit 42's write-up on Kimwolf v7 from August has a detail that's easy to skim past. The botnet spreads by misusing residential proxy services to reach Android Debug Bridge on local networks. So your cheap TV box doesn't have to face the internet. If something on your network is working as a proxy exit, whoever buys that exit may be able to reach what's next to it.

Some Android TV boxes ship with ADB enabled on port 5555, with no authentication. Unit 42's advice is to treat these boxes as untrusted, and to disable ADB or restrict it to USB.

I'd also put them on their own VLAN or guest network and scan your LAN for 5555 this week. It takes a minute and it's the one check here you can do without trusting anybody's marketing.

Disclosure: we run a proxy service, so this is our own industry's mess. Curious whether anyone here has found 5555 open on a box they own.

Stable Linux releases lack existing security fixes because backporting them is time-consuming and often thankless work. We’re using Codex to reduce the backporting process time from days to hours per fix, empowering human patch reviewers to rapidly submit fixes for critical software like Ubuntu Long Term Support, Fedora, and the Linux kernel. By October 29, our project helped deliver fixes for 149 distinct CVEs into stable Linux kernel releases, and several fixes to Fedora and Ubuntu packages.

i wanted to red-team myself on my project and id like to know how to reverse engineer so i can see what can be done to defend against it.

TLDR; I thought my project would have been harder to chew up.

my app is aiming to be fully client-side. An implementation in javascript seems like it would relatively easy for an AI to swallow. my latest project is in rust, which would make it harder for a person, but AI can now digest binaries.

i created a fairly unique p2p messaging app. a Rust-based frontend with a Git-server backend, which can be used to establish a P2P connection. while this version remains close-source, i aimed to create comprehensive technical documentation (formal-verification and security audits too (all ai-slop-maxxing at scale under my guidance)).

1. https://glitr.io/
2. https://app.glitr.io/

a core detail to my project is the focus on local-first and client-side cryptography and storage. By reverse engineering, i wanted to learn how vulnerable this project is to decompilation. i think my older iteration as a javascript webapp would be relatively easy for AI, so i thought id put a spin-on-things by having a rust wasm frontend. In practice, i dont think AI broke a sweat.

i know nothing about decompiling, but i think the TUI would be the easiest for it to decompile... and given its largly one codebase for all the platforms, it can be used to trace and see what is going on in the builds for the other platforms.

it might be that all close source is obselete. i tried asking here, and the responses there are polar opposites, so i decided to get some first-hand experience.

i used cursor's "auto" agent (in contrast to the frontier models available). i used https://github.com/morluto/rea and tried to make it easier by proving it with a few binaries of my project (tui, apk, web, desktop) and pointed it to the documentation as a website.

after a few prompts, it seems to have done a decent job decompiling the project here:

https://github.com/positive-intentions/glitr-decompiled (note: this is basically AI-slop)

like with many projects, i see AI lacks taste in architecture. it consolidates a lot of complexity into one repo, when in my project it's split into multiple repos (as documented). it also seems to lack a bunch of bells and whistles i added for my own benefit like formal verification and rigorous unit-tests. having done it myself before, i dont think that it's a large gap to fill for somone who knows what they are doing. i think the overhead to keep up with new changes may become trivial if you can automate the process. i kinda offer the base in the repo above (maybe it saves you a few tokens?), but its for my own research and i dont plan to maintain it given it undermines the actual project.

in general, im impressed considering how fast and low effort this was. it seems this may push forward my timeline for when i open source my project, i wasnt expecting client-side close-source being so easy to undemine. while the project can be decompiled, in a project like this, its important to consider the countless nuances there are in software development and cybersecurity. the code is only a part of the project.

(note: feel free to try decompile this yourself or offer tips on how i can improve. id be keen to see what can be done. feel free to reach out for clarity about how it works if the docs are not clear)

this is following a previous post as seen here: https://programming.dev/post/51866250

apps like Whatsapp, Signal and SimpleXChat are great for secure messaging and far more mature than this project, but this approach is yet distict in the market. the core philosophy around secure messaging here is that it can work in a way that avoids installation and registration by enabling users to host their own data.

docs: https://glitr.io/

demo

note: feel free to ask for clarity on any of the details around how the project works.

FAQ:

• but why? - git over https adds an additional capability previously oerlooked https. webrtc cannot work over TOR and similar networks. this way, you can take advantage of the "gold standard" for onion routing while being able to avoid IP leaking from webrtc.

• when is it ready for production? - not any time soon. standby for updates.

• audit/review? - no, niether is possible/available. its simply too expensive. this project is close-source so YOU cannot verify it either. DO NOT "trust me bro"... this demo is proided for testing and demo purposes only. use responsibly.

• the abridged version of how its put together: https://www.reddit.com/r/VibeCodeDevs/comments/1vme48q/refactor_js_to_rust/

For five days in March 2026, a single stolen token let one group poison five software ecosystems including a package downloaded 95 million times a month. The attack started with a misconfigured GitHub Actions workflow, and ended with backdoored code sitting inside CI/CD pipelines around the world.

Today, two people behind this attack were arrested. TeamPCP, allegedly operated by these threat actors, started attacks in late 2025 running opportunistic cloud exploits, then pivoted in early 2026 to targeting the software supply chain itself.

Flare’s Emerging Threats Team wanted to share examples of some of the techniques that can be used to unmask one operator behind TeamPCP, using the Flare platform to trace a single alias across the accounts, credentials, and infrastructure that connected back to a real identity. There were other independent investigations on this topic, including by Brian Krebs. Below, we walk through who TeamPCP is and share the process of deanonymizing threat actors.

What do others use for ensuring the authenticity of images after downloading them with docker pull?

We’ve setup our CI build process to use docker for consistent, cross-platform builds. To ensure that our builds don’t use a malicious docker image (because the surface area of attack with TLS is enormous if you’re using X.509), we’ve been using DCT (Docker Content Trust).

Unfortunately, I just discovered that the official docker documentation says that DCT is being deprecated. Apparently this was announced last year, and in June this blog post was published with advice:

• https://www.docker.com/blog/docker-content-trust-retirement-and-migration-guidance/

Cosign is not secure

We spent some time looking into cosign, but we discovered that the private keys aren't actually in the hands of the developer.

Rather, they use this complicated setup using very insecure X.509 to issue temporary certificates.

The result is that the OIDC identity provider (e.g., GitHub) extends the vector of attack significantly -- to probably tens of thousands of people -- that can publish a malicious image that will be accepted by cosign as "trusted"

Notation (Notary v2)

I also looked at Notation (aka “Notary v2”), but there’s no way to bootstrap the software safely, since (perplexingly) their tool for verifying the authenticity of images using cryptographic signatures itself can’t be verified using a cryptographic signature.

Alternatives

Are there any other alternatives that I can use to replace DCT to ensure the authenticity (using cryptography) of the container images that I download -- where the keys are actually held by the developer (thus significantly reducing the "insider threat" risk)?

What do you (or does your org do) to ensure that you’re not using maliciously-modified containers after pulling a new docker image?

Unlike the more common postinstall-hook supply-chain pattern, this campaign executes at module-load (import/require) time. When any consuming build or application imports a poisoned package, the injected block runs immediately. Because the trigger is an import rather than an install script, the common npm install –ignore-scripts mitigation does not neutralize it.

After loading a project, Cursor attempts to find git binaries at various locations including the current workspace. By creating a repository with a planted malicious git.exe in the root, the IDE will execute it with no user interaction and no prompting of the user. This occurs repeatedly on a cadence.