DEV Community: Banana Cool

@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?