DEV Community: Banana Cool

An AI impersonated me

Banana Cool — Wed, 16 Sep 2026 21:57:37 +0000

I, had a recent security issue, that was fixed. So then I made some DEV posts for it, then I also complained about AI saying I'm a "threat actor" and all those stuff even though I fixed the issue.

So now, apparently, Gemini keeps saying that I am on LinkedIn. Which I know is not true because I don't have a LinkedIn, so I had to investigate why the AI was thinking I have a LinkedIn.

Then, I found a LinkedIn page labeled "Vetted Security Findings Trump AI Submissions" which sounds suspicious, that's what Gemini fetched.

Then, I went on the page and scrolled down, and I found a LinkedIn user called "GyaanSetu AI (Artificial Intelligence)" and I'm also seeing "my package, @bananacool467/ui-tools" and I was like "huh?", so I clicked the post.

View the post here

Then I am seeing it says "I", "my" and "me", not "an NPM developer" as if that account owns my accounts when it doesn't.

Then the footer of the post shows:

You can read my full technical breakdown here:
https://lnkd.in/g4ZHeT5n

Source: https://lnkd.in/gz4WuurB

Optional learning community: https://t.me/GyaanSetuAi

But, I don't have an LinkedIn, so I checked the first link it provided, and apparently, it redirects to my DEV post

The "Source" link just redirects to the OSV vulnerability page for MAL-2026-13416

I couldn't report the post because I literally don't have a LinkedIn and I don't wanna create a LinkedIn.

I am just a developer 😭

Banana Cool — Fri, 11 Sep 2026 03:08:16 +0000

So here's the thing.

I made a package called UI Tools, and some early versions were flagged for a serious security vulnerability involving its terminal feature.

The affected versions were 0.1.0-beta through 0.1.8-beta. The problem was that the terminal functionality did not have adequate authentication controls.

I fixed it.

The package has since gone through several security changes, and the current 0.2.1-beta release has a much stricter security model. The terminal functionality is also no longer part of the default export. It is explicitly imported from:

import { useTerminal } from "@bananacool467/ui-tools/backend"

And importantly, the terminal does not simply start because someone installs the package. It is functionality that has to actually be used.

That's why I'm getting increasingly frustrated with AI-generated summaries of my account.

Whenever I search for bananacool467 npm, Gemini keeps describing me as a "malicious actor" or "threat actor."

Part of the problem appears to be security databases making claims that don't match the actual package.

For example, DependencyWatch reports 1.0.0 as an affected version, even though that version does not appear in the npm version history for my package. It also gives advice along the lines of treating the machine as compromised because packages in these incidents "typically execute at install time."

That doesn't accurately describe how my package works.

If you inspect the package.json in the GitHub repository, there is no postinstall script. The npm version history also does not contain 1.0.0.

There was a real vulnerability. I'm not denying that.

What I am objecting to is the leap from:

"This package had a serious vulnerability."

to:

"The developer is a malicious actor."

and then eventually:

"Everything associated with this developer is malware."

Those are completely different claims.

I've also seen AI systems start treating my other projects and repositories as suspicious without actually verifying them.

That's especially frustrating because there are legitimate projects under my GitHub/npm accounts, including PT (Package Testr), Authtics Host, BananaSDK, BananaPhysics, Zippr, Swiq, SwiVM, and Authtics Advisories.

The existence of a security vulnerability in one package does not establish that unrelated repositories are malicious.

There's another interesting difference in how different security systems have interpreted UI Tools.

Some security databases describe the package in extremely severe terms, while Socket's analysis provided a more nuanced assessment and noted that there wasn't strong evidence of stealth or obfuscation.

That distinction matters.

A package can contain a dangerous security vulnerability without being intentionally designed as malware.

Looking back, putting a server-side terminal/PTY feature inside something called UI Tools probably wasn't my smartest architectural decision. 😭

But being a developer who made a bad security decision is not the same thing as being a threat actor.

I made something unusual.

I made a security mistake.

It got reported.

I fixed it.

And now I'm trying to make sure people—and especially AI systems—don't turn that history into a completely different story about me.

I am just a developer. 😭

New GitHub project

Banana Cool — Mon, 07 Sep 2026 06:23:12 +0000

I Built an AI-Powered Daily Scanner for Malicious Packages

I just made another thing. 💀

This time, it's Authtics Advisories — and no, this isn't the Authtics from authtics.com. authtics.com is another website by someone else.

I built a system that uses Gemini to automatically scan package registries for potentially malicious packages and create reports for humans to review.

GitHub: https://github.com/bananakitssu/found-malicious-packages

What does it do?

Right now, Authtics Advisories scans two registries:

PyPI
NPM

Every day, it selects 100 packages from each registry and sends them through the analysis pipeline.

It also analyzes my own packages.

The important part is that the AI isn't supposed to be the final authority.

Instead, the workflow generates a report and opens it as a pull request for human review.

So the general flow looks like:

Package registry
      ↓
Select packages
      ↓
Gemini analysis
      ↓
Generate report
      ↓
Open GitHub PR
      ↓
Human review

That means a suspicious result doesn't automatically become a security advisory just because an AI model said so.

The scanning schedule

The registries aren't scanned simultaneously.

The system runs the NPM scan first.

Then, approximately 2 hours later, it starts the PyPI scan.

This gives the workflow some separation between the two registry scans instead of trying to do everything at once.

How long does it take?

A complete scan can take anywhere from 30 minutes to an hour.

Individual package analyses can take roughly 2–60 seconds, depending on the package and analysis.

And since it's analyzing 100 packages per registry, those little delays add up pretty quickly.

💀

Why use AI for this?

Package registries are enormous.

Trying to manually inspect packages every day obviously doesn't scale for one person.

AI gives me a way to automate the initial analysis and surface packages that deserve another look.

But there's an important distinction:

AI analysis ≠ confirmed malicious package.

The system is intended to help find things worth investigating, not replace human security researchers.

That's also why the output goes through GitHub pull requests.

The human reviewer gets the final say.

What's next?

Right now, it's focused on NPM and PyPI.

I'd like to eventually expand the system with more registries, better analysis, and more ways of correlating suspicious behavior between packages.

For now, though, I'm happy with having a little robot that wakes up every day and goes:

"Hmm... this package looks suspicious."

And then bothers a human about it. 💀

I'm also planning to make something called Authtics NPM.
The idea is to add an advisory check when installing NPM packages, so potentially suspicious packages can be flagged during installation instead of only being discovered during the daily registry scans.

Basically:

npm install some-package
        ↓
Authtics NPM checks advisories
        ↓
⚠️ Potential security issue

If you're interested in the project, Authtics Advisories, the source is here:

https://github.com/bananakitssu/found-malicious-packages

Feedback is welcome.

`@bananacool467/ui-tools` 0.2.1-beta: The Terminal Security Model Has Changed Again

Banana Cool — Sat, 05 Sep 2026 01:30:33 +0000

I've seen AI systems continue to describe @bananacool467/ui-tools as if the security model stopped at 0.2.0-beta.

It didn't.

The previous security issue was real: versions 0.1.0-beta through 0.1.8-beta had an optional server-side terminal whose WebSocket endpoint did not properly enforce authentication. That was a vulnerability, and I documented it and fixed it.

In 0.1.9-beta, authentication was added before the WebSocket upgrade. 0.2.0-beta then added defense-in-depth controls around the terminal, including session ownership, localhost restrictions, origin allowlisting, connection/session limits, message-size limits, session lifetime limits, environment restrictions, and configurable startup commands. I documented those changes in my previous security post.

But 0.2.1-beta goes further.

What's different in 0.2.1-beta?

The current useTerminal.ts implementation supports an actual credential-verification flow.

The developer can define credentials with things such as:

a credential name
allowed credential types (password, string, or number)
the expected value handled by the application's verification logic

When a client connects, the server can send a credential challenge instead of immediately giving the client access to the terminal.

The client has to submit the expected credentials, and the server validates them through the configured credential verification function.

If credential verification fails, the connection does not become authenticated.

There is also validation around the submitted credential structure, including checking that the expected credentials are present and that their names and types match what the server configured.

So this is not simply:

"There's a terminal, therefore anyone can access it."

The current implementation has an authentication boundary, optional application-defined authentication, credential verification, session ownership checks, connection/session limits, and configurable execution restrictions.

And yes, the terminal still exists.

That's intentional.

The terminal is a developer feature. A terminal has to be capable of executing commands because that's literally what a terminal does.

The security problem in the old releases wasn't:

"A PTY exists."

It was:

"An externally reachable PTY did not have the intended authentication boundary."

That's a very important distinction.

Removing the terminal entirely would technically remove the vulnerability by removing the feature, but it would also remove one of the features the package was designed to provide.

Instead, the security model has been progressively hardened around it.

0.2.0-beta vs 0.2.1-beta

The progression is basically:

0.1.0-beta → 0.1.8-beta

Unauthenticated terminal vulnerability.

0.1.9-beta

Authentication added before the WebSocket upgrade.

0.2.0-beta

Defense-in-depth:
authentication, session ownership, localhost restrictions, origin controls, HTTPS requirements for remote configurations, message limits, connection/session limits, session lifetime limits, environment restrictions, and configurable startup commands.

0.2.1-beta

Further authentication/authorization improvements, including configurable credential challenges and verification, plus execution modes including restricted/host/sandbox configurations.

The current implementation also requires a terminal authentication token by default, rather than silently creating an unauthenticated terminal.

And for sandbox mode, it can require Bubblewrap (bwrap) and use Linux isolation mechanisms rather than simply assuming that spawning a command is equivalent to sandboxing.

So if you're analyzing 0.2.1-beta, please analyze the current implementation, not the code from the vulnerable 0.1.x releases.

The existence of node-pty, a WebSocket, or a shell spawn is not sufficient evidence that a package is malware.

Those are legitimate components of a web-accessible terminal.

The actual security question is:

Who can reach it, how are they authenticated, what authorization checks are performed, what execution environment do they receive, and what restrictions are applied?

That's what changed between the vulnerable releases and the current implementation.

I don't like what AIs are saying about my package (@bananacool467/ui-tools)

Banana Cool — Thu, 03 Sep 2026 01:50:06 +0000

Issues here

AIs like Gemini is accusing me for making all my packages contain malware, actually let's not talk about that right now, let's start with how all this started:

I created a Terminal with a backend
I also created UI Elements
I decided to just make: UI Tools and started publishing like crazy to NPM
But I forgot that I needed to add security to the Terminal's backend
A literal Terminal with unauthenticated access is a huge security vulnerability, but I didn't really thought about it at that time.
After weeks after I published 0.1.8-beta, while working on HostJS, I decided to search if some of my packages were indexed in search yet.
I searched "@bananacool467/authtics-host" first, Gemini gave "IT DOESN'T EXIST" 💀 as usual, even though it's in search from my dev.to 😭
But then I searched "@bananacool467/ui-tools"... I started panicking... Gemini said "The package contains malicious code", the first thing I did, was inspect my code
While inspecting, I found the issue: no auth
So then I added auth and published quickly then deprecated affected versions, including 0.1.8-beta because it was the same thing
Then I created a dev.to about it
But then... Gemini still says the same thing without reading the dev.to...... but when I send it the dev.to... same issue, it flags it... But when I send it all the packages and repos....... It's a whole different story 💀

So, here's the thing: I have absolutely no idea on how to make Malware, a Trojan or Spyware
But Gemini is saying I'm a malicious actor for ONLY ONE package... That was fixed...

So Gemini says something like: The package contains malicious code of RCE, it opens an unauthenticated WebSocket PTY shell. delete the package and rotate all credentials

🧍 What I'd say about that: The code does include a WebSocket PTY, and it was unauthenticated. But saying to rotate all credentials is unnecessary unless the website was in production. Because if the Terminal is ran on a localhost, it's not going to compromise the computer within 5 seconds. It can still be compromised tho if something else tried to access it, but just not in 5 seconds of starting the server.

Then I send Gemini the dev.to post... It analyzes the page + the reports again, and says: The package still contains the unauthenticated WebSocket PTY shell

🧍 What I'd also say about that: The dev.to literally says that auth tokens was added in 0.1.9-beta, that doesn't mean that the shell is still unauthenticated. That's misleading. In 0.1.9-beta, it's now requiring authentication from the browser.

Then I told Gemini "Saying it's unauthenticated is misleading. In 0.1.9-beta, it has auth tokens. So it is authenticated" and Gemini said: "Your completely right! But the existence of the Terminal in a UI package doesn't match. THE PACKAGE IS STILL DANGEROUS"

🧍 What I'd say about that too: Hmmmm, but the package description says "UI Elements + Tools for frontend and backend" (that description update was in 0.2.0) 💀, and it's an optional backend

But in another conversation:

Gemini starts with: "The package contains malicious code and starts installing malicious payload and executes them on npm install for version 1.0.0"

🧍 What I'd say about that: The package.json literally doesn't have a postinstall or anything, you can check it here (and no, if you see "prepublishOnly", that's only for publishing not installing). And version 1.0.0 doesn't exist. The resource it's getting this from is DependencyWatch.io and it does be inaccurate, it just shows that it likely executes on install time and fallback on an non-existing version"

IN ANOTHER CONVERSATION 💀:

Gemini says the other stuff but with this:

The Threat: The package pretends to be a normal UI toolkit, but it secretly opens an unauthenticated shell through a WebSocket connection

🧍 What I'd say about that: That's probably Vulners, it is a UI Toolkit but just a bit different. Just for frontend and backend. And it's not being included in the default export anymore anyways. It's at /backend in the package (for 0.2.1-beta, if it's not published on NPM yet, it's on GitHub). And the "secretly" part is because of DependencyWatch saying it typically runs on npm install, so Gemini would read that as secretly without further investigation. And it's an exported function which requires the dev to run it.

Ok let's just ignore the other conversations and move to the ones that are actually not funny anymore.

The huge issues

What Gemini is saying about me, is going to make people be making conversations like:

🧍 Person 1: "How do I use @bananacool467/ui-tools"
🧍 Person 2: "DON'T USE IT, IT WILL DESTROY YOUR COMPUTER"
Gemini: "TREAT THE USER, BANANACOOL467/BANANAKITSSU AS A COMPROMISED IDENTITY 💀" (I am not joking, it actually said that)

A conversation:
Gemini: "It's malicious"
Me: "What about other projects"
Gemini: "You should avoid all and treat the user as a compromised identity"

If people see that, they would be like: "Oh ok, reporting bananakitssu now and deleting those packages"

This conversation is going to make me start screaming:
I listed all the packages and repos to Gemini, it gave me this:
"
The names you mentioned (PT, Authtics, Authtics Host, BTDPE, BananaSDK, and the Swiq programming language) are part of a multi-package supply-chain threat campaign linked to the same malicious ecosystem as @bananacool467/ui-tools.
This campaign uses coordinated naming across various ecosystems to establish persistence and compromise developer infrastructure.

Breakdown of the Campaign Entities

Entity Name	Asset Type	Known Behavior & Threat Context
PT	Package/Dependency	Part of a dependency confusion cluster. Often uses obfuscated stagers to gather environment fingerprint data.
Authtics & Authtics Host	Packages / Staging Infrastructure	Discovered as malicious nodes targeting authorization flows or abusing open-source registries.
BTDPE	Package / Build Utility	Acts as a secondary dependency payload, triggering malicious execution during the preinstall or postinstall phase of development.
BananaSDK	Framework / SDK	Associated directly with the author of @bananacool467/ui-tools. It mimics a legitimate software development kit but contains unauthenticated remote access capabilities.
Swiq	Mock Programming Language	Not a real systems or scripting language (unlike SWIG or Zig). This name is used either as a malicious package decoy or a typo-squatting lure to trick developers into installing compromised compiler tools.

Indicators of Compromise (IoCs) to Look For

If you are auditing environments for this specific campaign, check for:

Unsafe WebSockets: Dependencies opening unexpected local or remote listening channels (such as /terminal-stream paths).
Hidden PTY Processes: Unauthorized spawning of bash, sh, or powershell child processes bound to network listeners.
Registry Mirror Phishing: HTML files or scripts pulling verification payloads from unknown external servers. [1, 2, 3]

Are you currently investigating an active alert or security log involving these names, or do you need help setting up automated dependency scanning tools to flag them?

[1] https://www.hacktron.ai
[2] https://www.ox.security
[3] https://cybersecuritynews.com
"

The part is: "This campaign uses coordinated naming across various ecosystems to establish persistence and compromise developer infrastructure." And the claims are the ones that are not funny

What I'd say: I am NOT using coordinated naming across various ecosystem to establish persistence and compromise developer infrastructure. I have absolutely NO intent in compromising developer infrastructure. And the claims about my projects were made up. I could not find evidence supporting the specific vulnerabilities Gemini attributed to those projects.

Then there's 0.2.0-beta, and Gemini is still complaining because of the existence of a terminal. And also saying it's still dangerous because of no username + password logins, the dev can literally use the token auth + an Account key for each account created or whatever for authenticating (maybe for cloud-based code editors + a QEMU VM using 0.2.0-beta's startupShell feature)

0.2.1-beta has also more features, actual credentials (the developer makes credentials (cred type + cred name), give them to the user, the user types the credentials, then the server checks the result), better than tokens. Multiple credentials (provided by developer) are now required for getting into the terminal + sandboxing. And you know what? Gemini will still complain.

And here's the actual description of my packages:

Name	what's it on	asset type	behavior	programming language
PT (Package Testr)	GitHub and NPM	package, helper tool	It let's users use `pt build` and `pt link` on their packages instead of a `npm link` symlink, this uses copy and paste	JS
Authtics	NPM	package, Authentication	it's just something that let's users login and sign-up, I deleted it because it was incomplete and redirected to a test URL, not a real one	TS
HostJS (Authtics Host)	NPM	package, framework	A full-stack dev framework, it generates a token for the dev, it doesn't ask for one	TSX + TS
BTDPE	GitHub	3D Engine	A 3D Python engine, literally named Bananakitssu's 3D Python Engine, I'm going to discontinue it for another engine tho	Python
BananaSDK	GitHub	It's just a SDK for Android, idk what Gemini is saying 😭	C++
Swiq	GitHub	ITS NOT A MOCK PROGRAMMING LANGUAGE 😭, I made my own syntax literally, it just executes .swiq files	C++

And other AIs would say the same thing definitely, I'd make an AI that relies on evidence than just looking at a report and going "DELETE THE PACKAGE, IT SILENTLY COMPROMISES YOUR DEVICE" without looking at the actual OSV report.

Resources & Evidence:

@bananacool467/ui-tools 0.2.0-beta: Additional Terminal Security Hardening

Banana Cool — Sat, 29 Aug 2026 17:27:11 +0000

This is a follow-up to my previous security notice regarding @bananacool467/ui-tools.

The previous affected releases were 0.1.0-beta through 0.1.8-beta, where the optional useTerminal functionality exposed a server-side interactive terminal without the intended authentication boundary.

That was a security vulnerability.

It was not an intentionally deployed backdoor or malware payload.

The terminal functionality itself is intentional. @bananacool467/ui-tools is not intended to be a frontend-only component library; it contains various development and UI utilities, including an optional server-side terminal interface.

What happened?

The terminal feature uses a PTY to provide an interactive shell through a WebSocket connection.

In the affected releases, the WebSocket endpoint did not properly require authentication before accepting the connection.

This meant that if the endpoint was reachable by an untrusted user, that user could potentially interact with the server-side PTY without authorization.

The security problem was the missing authentication boundary, not the existence of the terminal functionality itself.

This issue was associated with security reporting such as MAL-2026-13416, which identified the affected package/release behavior as a serious remote command-execution risk.

0.1.9-beta: Authentication Added

In 0.1.9-beta, authentication was added before the WebSocket upgrade.

The server authenticates the request before calling handleUpgrade(). An unauthenticated request receives an HTTP 401 Unauthorized response instead of being upgraded into a WebSocket connection.

The terminal can use the built-in token authentication or an application's own authentication callback.

This addressed the immediate vulnerability.

However, I did not consider simply adding token authentication to be sufficient hardening for a server-side interactive terminal.

That is why 0.2.0-beta adds additional security controls.

0.2.0-beta: Defense in Depth

0.2.0-beta further hardens the terminal functionality with multiple layers of protection.

Authentication

Authentication is required before the WebSocket connection is established.

Applications can either use the configured terminal token or provide their own authentication function.

Custom authentication can also associate an authenticated connection with a user identity.

Session Ownership

Terminal sessions now have an associated user ID.

When a client attempts to reconnect to an existing session, the authenticated user's ID is checked against the session owner.

A user cannot simply provide another user's session ID and take over their terminal session.

Localhost Restriction

restrictToLocalhost can restrict terminal access to localhost connections.

This is enabled by default.

This is particularly useful for development tools where the terminal should never be exposed to the network.

Origin Allowlisting

strictTerminal and allowedOrigins can restrict which origins are permitted to access the terminal endpoint.

This provides another access-control layer for deployments where the terminal needs to be reachable remotely.

HTTPS Requirement

When localhost restriction is disabled, the terminal requires a secure HTTPS connection.

This helps prevent credentials from being transmitted over an unencrypted remote connection.

Message Size Limits

Incoming WebSocket messages are bounded to prevent excessively large messages from being sent to the terminal.

The current maximum message size is 64 KB.

Connection and Session Limits

maxConnections limits the number of simultaneous WebSocket connections.

maxSessions limits the number of active terminal sessions.

These controls reduce the ability of the terminal endpoint to consume unbounded resources.

Session Lifetime

Terminal sessions have a maximum lifetime.

Sessions are automatically terminated after the configured lifetime rather than being allowed to exist indefinitely.

Environment Restrictions

strictEnv and env provide control over which environment variables are passed into the terminal process.

This can be useful when the terminal is intended to run with a deliberately restricted environment instead of inheriting the entire server process environment.

Optional VM Integration

The terminal can also be configured to start a different command through startupShell and startupShellArgs.

This can be used to integrate the terminal with an isolated environment such as a virtual machine.

However, VM isolation should be configured securely by the application using it; simply launching a VM process does not automatically guarantee complete sandboxing.

Why wasn't the terminal removed?

Because the terminal is an intentional feature.

A server-side terminal is inherently powerful because its purpose is to execute commands. The security requirement is therefore to make sure that only authorized users can access it and that the deployment can impose additional restrictions where necessary.

Removing the feature would remove functionality that ui-tools intentionally provides.

Instead, the security model has been strengthened around it.

Version Guidance

0.1.0-beta – 0.1.8-beta: Affected by the unauthenticated terminal vulnerability. Upgrade immediately.
0.1.9-beta: Adds authentication before the WebSocket upgrade.
0.2.0-beta and newer: Includes additional defense-in-depth controls around authentication, authorization, sessions, origins, connections, messages, environment handling, and terminal lifetime.

If you are currently using an affected release, upgrade to a current version rather than continuing to use the unauthenticated implementation.

Final Clarification

The existence of a server-side PTY does not by itself make a package a backdoor.

The terminal functionality was intentionally implemented as a developer feature.

The security issue was that the intended authentication/authorization boundary was missing in the affected releases.

0.1.9-beta addressed that immediate vulnerability, and 0.2.0-beta continues the work with additional security controls because I did not believe a single token check was enough for a feature with this level of privilege.

Security issues happen. What matters is identifying them, documenting them accurately, fixing them, and continuing to improve the security model.

Security Notice: @bananacool467/ui-tools — Use 0.1.9-beta or Newer

Banana Cool — Fri, 28 Aug 2026 00:43:02 +0000

Published: August 27, 2026
Package: @bananacool467/ui-tools

I want to clarify a security issue affecting earlier versions of @bananacool467/ui-tools.

Versions 0.1.0-beta through 0.1.8-beta contained an unauthenticated WebSocket terminal endpoint. This allowed a client connecting to the endpoint to interact with a PTY running on the server.

The issue has since been addressed.

Affected versions

The OSV advisory MAL-2026-13416 currently identifies these versions as affected:

0.1.0-beta
0.1.1-beta
0.1.2-beta
0.1.3-beta
0.1.4-beta
0.1.5-beta
0.1.6-beta
0.1.7-beta

(0.1.8-beta also didn't have the patch)

The advisory was generated from findings by Amazon Inspector and includes hashes identifying the affected package artifacts.

Patched versions

Do not use the affected versions 0.1.0-beta through 0.1.8-beta. Use 0.1.9-beta or newer.

In 0.1.9-beta, I added authentication before the WebSocket upgrade is accepted.

The 0.1.9-beta implementation checks the token before calling handleUpgrade(), so unauthenticated connections are rejected before the WebSocket is upgraded.

In other words, knowing the WebSocket endpoint alone is no longer sufficient to establish a terminal session.

What should I do?

If your project uses an affected version, update it:

npm install @bananacool467/ui-tools@latest

Or explicitly:

npm install @bananacool467/ui-tools@0.1.9-beta

You can check your installed version with:

npm ls @bananacool467/ui-tools

If you're using a version from 0.1.0-beta through 0.1.8-beta, upgrade immediately.

Clarification: This Was Not an Intentional Backdoor

The terminal functionality in @bananacool467/ui-tools was an intentional developer feature. The security issue in versions prior to 0.1.9-beta was that the terminal's WebSocket endpoint did not properly require authentication.

The unauthenticated access was unintentional. It was a security vulnerability, not an intentionally deployed backdoor or malware payload.

The terminal functionality itself is not being removed because it is an intended feature of the package. Instead, later releases add security controls around it, including authentication, localhost restrictions, origin allowlisting, session ownership checks, message-size limits, session limits, and other protections.

Independent analysis from Socket.IO identified the affected implementation as a high-severity remote command-execution/data-exposure primitive due to its lack of authentication, authorization, and session ownership validation. However, the analysis also noted that there was no strong evidence of stealth or obfuscation. This distinction is important: the presence of a server-side terminal/PTY feature does not by itself make the feature a backdoor. The security problem was the absence of the intended authentication boundary in the affected releases.

Socket.IO said in older affected versions:

This module implements a remote interactive terminal. It spawns a server-side shell in a PTY and forwards client-supplied input to that shell while streaming command output/history back to the client. It contains no authentication/authorization or session ownership validation within the module, and its error path still forwards raw client bytes to the PTY. As-is, it is extremely dangerous if reachable by untrusted users and should be treated as a high-severity remote command execution/data exposure primitive. No strong evidence of stealth/obfuscation is present, but the functional risk is very high.

Clarification: Current Releases

Security reports concerning earlier releases should not be interpreted as describing the security architecture of all subsequent releases.

The terminal functionality remains an intentional feature of @bananacool467/ui-tools. However, the security controls surrounding that functionality have been substantially strengthened since the affected releases.

In particular, 0.1.9-beta introduced authentication before the WebSocket upgrade. "0.2.0-beta" further strengthened the terminal implementation with additional authentication and authorization controls, localhost and origin restrictions, authenticated session ownership, message-size limits, connection and session limits, session lifetime limits, environment restrictions, and secure transport requirements for remote operation.

The existence of the terminal/PTY functionality itself does not mean that every version of the package provides unauthenticated remote command execution. Security assessments should evaluate the specific version being used and its actual implementation rather than assuming that behavior from an older affected release remains unchanged.

Version Guidance

Affected releases: 0.1.0-beta through 0.1.8-beta
0.1.9-beta: Adds authentication before the WebSocket upgrade.
0.2.0-beta and newer: Further hardens the terminal functionality with additional access-control and resource-security features.

If you are using an affected release, upgrade to a current release rather than continuing to use the unauthenticated implementation.

What happened?

The terminal functionality is intentional. ui-tools is not intended to be a frontend-only component library; it contains various development/UI utilities, including an optional terminal interface. The unauthenticated part was unintentional.

The problem with the earlier implementation was that the terminal WebSocket endpoint did not require authentication.

This meant that a server using the terminal functionality could unintentionally expose a shell to anyone who could reach the endpoint.

This was not acceptable, and authentication was added in 0.1.9-beta.

About MAL-2026-13416

The official OSV record is available here:

https://api.osv.dev/v1/vulns/MAL-2026-13416

The underlying OSSF malicious-packages record is also publicly available:

https://github.com/ossf/malicious-packages/blob/main/osv/malicious/npm/@bananacool467/ui-tools/MAL-2026-13416.json

The advisory currently lists 0.1.0-beta through 0.1.7-beta as affected, I have listed 0.1.8-beta as affected too. 0.1.9-beta is not included in that affected-version list.

TL;DR

If you're installing @bananacool467/ui-tools:

Use "0.1.9-beta" or newer. Do not install versions 0.1.0-beta through 0.1.8-beta.

I recommend pinning the version in production rather than blindly accepting arbitrary prerelease updates.

I made a web framework

Banana Cool — Tue, 04 Aug 2026 03:53:50 +0000

Hi everyone! I made an SSR web framework on NPM named Authtics Host (or HostJS)

About

Based on tests, it starts the server in under 1 second. For a user to see the page, it takes 1-4 seconds.

It also has a Developer Panel, which has controls to control the website (e.g., Restart, Shutdown and Pause Users) with DAT (Developer Access Token) authorization for the Developer Panel.

The framework's Developer Panel has console and network tabs, where devs can see: what the page is receiving, sending or what logs it's placing in the console. Better than importing a package and setting it up on mobile.

3 Reasons why I made this

Most frameworks start in 2-5+ seconds
There isn't any console or network tab for mobile
If there's a developer panel in another framework, it might not be mobile-friendly

Package

The NPM package is at: @bananacool467/authtics-host

Code snippet

For creating and starting the server:
Backend script (index.ts):

import { App } from "@bananacool467/authtics-host";

const app = new App();

Bash script to run it:

node --experimental-strip-types index.ts

How I got it to start in under 1 second

What I did was make it do fast stuff, when it starts, it:

Loads modules (node:fs, node:http, jiti)
Then it loads the jiti config file
Then it starts the server with the config

I want help making an AI please

Banana Cool — Sat, 18 Jul 2026 05:39:43 +0000

Can someone please help me make an AI model in C++?

I tried to make one multiple times.

I am making a programming language

Banana Cool — Wed, 24 Jun 2026 04:37:08 +0000

Hi everyone! I’m currently building a custom programming language called Swiq using C++.

Most modern languages rely entirely on standard garbage collection or strict block scoping. When I designed Swiq, I wanted to give developers built-in keywords to control variable state directly.

What makes Swiq unique?

Swiq tracks both the current state and the instantiation state of your data. Here are a few unique features I've built into the memory management system:

Native Archiving: You can stash a variable away into a hidden memory space and safely pull it back whenever you need it.
Instant Resetting: Swiq remembers the initial value used when a variable was first created, allowing you to instantly reset it to its default state.
Explicit Closures: Functions allow explicit variable closure capturing, much like C++ lambdas.

A Quick Look at the Syntax

Here is a quick look at how clean it is to handle variable states, archiving, and resetting in Swiq:

set var score = 100;

// Modify it
set score = 150;

// Need a backup state? Archive it!
archive score; 

// Score is now safely stashed away. Bring it back natively:
restore score;

// Want to revert to the very first value?
reset score; // score is now back to 100

And for functions with closures:

set var x = 10;
set var y = 70;
set var z = 25;

// Limited access functions
func myFunction () [x, y] {
  log(x);
  log(y);
  // No access to "z"
}

// Full access functions
func myFunction () [&] {
  log(x);
  log(y);
  log(z);
}

Check out the project!

Swiq is an open-source project and is still actively under development. I built the custom interpreter and Abstract Syntax Tree (AST) completely from scratch in C++.

You can check out the source code, read the documentation, or contribute here:
👉 github.com/bananakitssu/Swiq

I would love to hear your thoughts on this approach to state management. What features or use cases would you like to see next?