CVE-2026-23486: Blinko Information Disclosure Flaw

CVE-2026-23486 Overview

CVE-2026-23486 is an Information Disclosure vulnerability affecting Blinko, an AI-powered card note-taking project. Prior to version 1.8.4, a publicly accessible endpoint exposes all user information, including usernames, roles, and account creation dates. This vulnerability allows unauthenticated attackers to enumerate user accounts and gather sensitive information that could be leveraged for further attacks.

Critical Impact

Unauthenticated access to sensitive user data including usernames, roles, login types, and account creation timestamps through an exposed public API endpoint.

Affected Products

• Blinko versions prior to 1.8.4
• Blinko note-taking application with exposed /v1/user/public-user-list endpoint
• Self-hosted Blinko instances without network-level access controls

Discovery Timeline

• 2026-03-23 - CVE-2026-23486 published to NVD
• 2026-03-24 - Last updated in NVD database

Technical Details for CVE-2026-23486

Vulnerability Analysis

This vulnerability stems from improper access control in the /v1/user/public-user-list API endpoint within Blinko's tRPC router. The endpoint was designed to return a list of users for public-facing features but inadvertently exposed sensitive user attributes that should have been restricted.

The vulnerable implementation returned extensive user information including internal identifiers, usernames, role assignments, login types, account creation and modification timestamps, and linked account references. This data exposure violates the principle of least privilege and provides attackers with valuable reconnaissance information.

An attacker can leverage this information disclosure to identify administrative accounts, understand the user base composition, and potentially craft targeted attacks against specific users based on their roles or account characteristics.

Root Cause

The root cause is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). The vulnerable endpoint lacked proper filtering of sensitive user attributes before returning data to unauthenticated requesters. The API schema was overly permissive, including fields such as name, role, loginType, createdAt, updatedAt, and linkAccountId that should not be publicly accessible.

Attack Vector

The vulnerability is exploitable over the network without authentication. An attacker can simply send an HTTP GET request to the /v1/user/public-user-list endpoint to retrieve the complete list of user information. No special privileges, user interaction, or complex attack chains are required.

// Security patch in server/routerTrpc/user.ts
// Source: https://github.com/blinkospace/blinko/commit/ec1e3e20384b620b8bf928fe80b4d8546757b419

     .meta({
       openapi: {
         method: 'GET', path: '/v1/user/public-user-list', summary: 'Find public user list',
-        description: 'Find public user list without admin permission', tags: ['User']
+        description: 'Find public user list without admin permission. Only returns non-sensitive information.', tags: ['User']
       }
     })
     .input(z.void())
     .output(z.array(z.object({
       id: z.number().int(),
-      name: z.string(),
       nickname: z.string(),
-      role: z.string(),
       image: z.string().nullable(),
-      loginType: z.string(),
-      createdAt: z.coerce.date(),
-      updatedAt: z.coerce.date(),
       description: z.string().nullable(),
-      linkAccountId: z.number().int().nullable()
     })))
     .query(async () => {
+      // Security fix: Only return non-sensitive public information
+      // Removed: name, role, loginType, createdAt, updatedAt, linkAccountId
       return await prisma.accounts.findMany({
         select: {
           id: true,
-          name: true,
           nickname: true,
-          role: true,
           image: true,

The patch removes sensitive fields (name, role, loginType, createdAt, updatedAt, linkAccountId) from the API response schema, limiting the endpoint to return only non-sensitive public information such as id, nickname, image, and description.

Detection Methods for CVE-2026-23486

Indicators of Compromise

• Unusual volume of GET requests to /v1/user/public-user-list endpoint
• Automated scraping patterns targeting user enumeration endpoints
• Access attempts from known malicious IP addresses or Tor exit nodes
• Bulk data extraction patterns in API access logs

Detection Strategies

• Monitor API access logs for unauthenticated requests to the /v1/user/public-user-list endpoint
• Implement rate limiting and anomaly detection on user-facing API endpoints
• Deploy Web Application Firewall (WAF) rules to detect and block enumeration attempts
• Enable detailed logging for all tRPC router endpoints to track access patterns

Monitoring Recommendations

• Configure alerts for high-frequency API requests from single IP addresses
• Implement application-level logging to capture request metadata and response sizes
• Review access logs periodically for signs of data harvesting or reconnaissance activity
• Monitor for downstream attacks that may leverage harvested user information

How to Mitigate CVE-2026-23486

Immediate Actions Required

• Upgrade Blinko to version 1.8.4 or later immediately
• Review API access logs to identify potential exploitation attempts prior to patching
• Audit all publicly accessible endpoints for similar information disclosure issues
• Consider implementing network-level access controls for self-hosted instances

Patch Information

The vulnerability has been patched in Blinko version 1.8.4. The fix modifies the /v1/user/public-user-list endpoint to return only non-sensitive user information. For detailed patch information, refer to the GitHub Security Advisory GHSA-446p-2xf5-frxf and the security patch commit.

Workarounds

• Implement network-level access restrictions to limit exposure of the Blinko instance
• Use a reverse proxy to block or require authentication for the /v1/user/public-user-list endpoint
• Deploy WAF rules to filter requests to sensitive API endpoints until patching is complete

# Example nginx configuration to restrict access to the vulnerable endpoint
location /v1/user/public-user-list {
    # Deny all access until patch is applied
    deny all;
    # Or require authentication
    # auth_basic "Restricted";
    # auth_basic_user_file /etc/nginx/.htpasswd;
}