Summary
Togoder Security scanned the Go package github.com/cloudwego/base64x@v0.1.6 on Oct 5, 2026. An AI review of 17 source files produced 12 medium, 5 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.
Findings 17
Use of linkname / unsafe package for internal linking
NPS-226F2EE837EC
The file uses Go's //go:linkname directive (implied by the comment 'because sonic-go linkname these') to expose internal variables _subr__b64decode and _subr__b64encode. This bypasses Go's type safety and encapsulation, allowing external packages to access unexported variables. While not inherently malicious, this pattern is a known vector for backdoor insertion because it can be used to silently link to arbitrary symbols and alter program behavior without explicit imports.
unsafe memory manipulation
NPS-5E5C61952858
The functions mem2str, str2mem, and noEscape use unsafe pointer arithmetic and reflect header manipulation to reinterpret memory between byte slices and strings. This bypasses Go's type and memory safety guarantees, allowing mutable aliasing of immutable strings. If a string returned by mem2str is later modified through the original byte slice, it can lead to undefined behavior, memory corruption, or subtle security vulnerabilities. The noEscape function intentionally hides pointers from escape analysis, which can be used to subvert garbage collector safety if misused.
indirect function call to native code
NPS-F48790C86281
F_b64decode is a function pointer (typically set to an AVX2 assembly implementation) that processes raw memory without bounds checking. The parameters (out, src, len) rely on the caller to provide valid, sized buffers. If len or pointers are attacker-controlled, this could cause out-of-bounds reads/writes.
unsafe pointer usage
NPS-9D57EB54C596
The code uses unsafe.Pointer and rt.NoEscape to bypass Go's type safety and escape analysis when passing pointers to an assembly (or externally linked) function F_b64decode. While this is typical for high-performance SIMD code, misuse could lead to memory corruption or undefined behavior.
unsafe pointer / FFI indirection
NPS-460A591D57C4
The function uses unsafe.Pointer and an externally-populated function pointer (F_b64encode) declared as a package-level var, with no Go implementation or binding present in this file. This delegates execution to code that is resolved or injected elsewhere (likely via runtime symbol linking or assembly). The purpose of B64encode is not visible or verifiable here, which prevents a full security review of the actual executed logic.
opaque native function invocation
NPS-6E582DCB1AD5
F_b64encode is a function variable of unknown origin. If populated via dynamic linking, reflection, or init-time assignment from an untrusted source, it could execute arbitrary native code. The actual implementation is not contained in this file, so the security posture depends on the rest of the package.
unsafe memory operations
NPS-DB2D96118174
The code uses the unsafe package to bypass Go's type safety and memory safety guarantees. Functions like B64Decode and B64Encode pass raw pointers (unsafe.Pointer) to external assembly functions (F_b64decode, F_b64encode) with size parameters. This could lead to memory corruption, buffer overflows, or arbitrary code execution if the external functions do not properly validate bounds or if malicious input is provided. The use of rt.NoEscape further suppresses escape analysis, which may allow pointers to stack memory to be passed to native code, potentially causing use-after-return vulnerabilities.
unsafe pointer conversions
NPS-D912060DE89C
The code converts *[]byte (pointer to slice) to unsafe.Pointer and passes it to native functions. This bypasses Go's memory safety and could be exploited if the native functions mishandle the pointer or if the slice is modified concurrently. The lack of validation on the 'len' and 'mod' parameters passed to F_b64decode means that out-of-bounds reads/writes are possible, which could lead to information disclosure or memory corruption.
function pointer assignment
NPS-A2EC71681A5C
F_b64decode is a package-level function variable that is not initialized in this file. Its value is presumably set by architecture-specific assembly initialization code. If an attacker can influence this assignment, they could redirect the B64decode function to execute arbitrary code. This is a common pattern in high-performance Go libraries but warrants attention.
unsafe pointer manipulation
NPS-2BE1098084E2
The code uses Go's unsafe package to pass raw pointers to a function variable (F_b64decode) that is externally assigned, with //go:nosplit directive. This bypasses Go's memory safety guarantees. While this appears to be legitimate SIMD/base64 decoding code from ByteDance's cloudwego project, the pattern of function pointer assignment (F_b64decode, S_b64decode) combined with unsafe pointer operations could potentially be exploited if the function variable is assigned maliciously at runtime.
unsafe pointer usage
NPS-2DB0F9BAE413
The code uses the unsafe package and unsafe.Pointer to convert between *[]byte and unsafe.Pointer. While this is a common optimization pattern in Go for performance-critical code, it bypasses Go's type safety and can lead to memory corruption if the pointers are misused. The function signatures and the use of rt.NoEscape suggest this is intentional for zero-allocation encoding, but it warrants caution.
Dynamic native code loading and execution
NPS-7AB6D5E39214
The generated file dynamically loads and links native C object code at runtime via loader.WrapGoC, binding C functions (b64encode/b64decode) into Go. While this is a legitimate performance optimization pattern used by sonic, runtime loading of native code can execute arbitrary machine code and bypass static analysis. The loading depends on embedded native text sections (_text_b64encode, _text_b64decode) defined elsewhere in the package. This warrants review of the accompanying native blobs and loader implementation to ensure no hidden or obfuscated native payloads are executed.
Import-time code execution (init function)
NPS-58C8F37C4D7E
The init() function runs automatically when the package is imported. It assigns values from the internal/native package to package-level variables. The values originate from native.S_b64decode and native.S_b64encode, which are likely platform-specific assembly symbols. While the current code only performs simple assignments, init() functions are a common execution point for malicious payloads, and the use of native assembly symbols could be a potential way to execute arbitrary machine code if the native package is compromised or if the assembly routines contain hidden functionality.
panic on unsupported CPU
NPS-14E353A42865
The init() function panics if the CPU lacks AVX2 or SSE support. While not malicious, this could cause denial of service on older hardware or in virtualized environments where CPU features are masked. This is a reliability concern rather than a security vulnerability.
external function call with raw pointers
NPS-AE230E2598F5
The function F_b64encode is called with unsafe.Pointer arguments derived from slices. If the function pointer is not properly validated or if the mode parameter is used to select different implementations, it could potentially be exploited if the mode is attacker-controlled. However, the code itself does not show any obvious malicious intent or data exfiltration.
unsafe pointer manipulation
NPS-9A1B68971ECB
Uses unsafe.Pointer and uintptr arithmetic to bypass Go's escape analysis and pointer safety. However, this is a well-known performance optimization pattern used in legitimate libraries (e.g., bytedance/sonic for JSON processing), not a malicious behavior. No data exfiltration, credential harvesting, or code execution.
external assembly dependency
NPS-3BFFEB0E6F2B
Declares an external function MoreStack(size uintptr) with //go:nosplit, likely implemented in assembly. While assembly can hide behavior, the function name suggests stack management, and no evidence of malicious intent.
Files reviewed
| File | Verdict | What the reviewer saw |
|---|---|---|
| base64x_subr_amd64.go | medium | The code uses Go linkname and an init function to expose internal symbols, which are atypical patterns that could facilitate backdoor insertion, though no direct malicious behavior is evident. |
| faststr.go | medium | The code contains unsafe memory reinterpretation via unsafe.Pointer and reflect headers, which although common in low-level performance libraries, can introduce memory safety and type confusion risks if misused. |
| internal/native/avx2/b64decode.go | medium | The code is a low-level base64 decode adapter using unsafe pointers and an external function pointer; although it exhibits unsafe memory handling common in SIMD libraries, no overt malicious patterns (exfiltration, backdoors, credential harvesting, etc.) were detected. |
| internal/native/avx2/b64encode.go | medium | This generated AVX2 wrapper uses unsafe pointers and an opaque native function pointer, which is normal for SIMD base64 acceleration but prevents full verification of the executed code from this file alone. |
| internal/native/dispatch.go | medium | The code uses unsafe memory operations and external assembly functions with raw pointers, posing medium-severity risks of memory corruption or exploitation, though no malicious patterns were detected. |
| internal/native/sse/b64decode.go | medium | Legitimate high-performance base64 decoding code using unsafe pointers and function pointer indirection, but the unsafe memory access patterns and uninitialized function variable present potential security concerns if the initialization code is compromised. |
| internal/native/sse/b64encode.go | medium | The code uses unsafe pointers for performance reasons but does not contain any obvious malicious patterns; it appears to be a legitimate base64 encoding optimization. |
| internal/native/sse/native_export.go | medium | The file uses a codegen'd runtime native-code loader (loader.WrapGoC) to bind embedded C base64 functions via exported Use(); it is not inherently malicious but relies on executing embedded native blobs that require further supply-chain verification. |
| base64x.go | safe | No malicious patterns detected |
| internal/native/avx2/b64decode_subr.go | safe | No malicious patterns detected in the generated assembly wrapper file. |
| internal/native/avx2/b64encode_subr.go | safe | No malicious patterns detected |
| internal/native/avx2/b64encode_text_amd64.go | safe | This file contains only a generated AVX2-optimized base64 encoder lookup table and assembly machine code, with no executable Go logic, network access, credential handling, or malicious patterns. |
| internal/native/avx2/native_export.go | safe | No malicious patterns detected in the AVX2 native export wrapper for base64 encoding/decoding functions. |
| internal/native/sse/b64decode_subr.go | safe | This is a generated assembly stub file for a base64 decoder with no suspicious runtime behavior, network calls, credential access, or dynamic code execution. |
| internal/native/sse/b64encode_subr.go | safe | This generated assembly stub for SSE base64 encoding contains only static metadata and function registration with no malicious behavior. |
| internal/native/sse/b64encode_text_amd64.go | safe | This is a legitimate generated assembly data file implementing Base64 encoding for amd64 with no malicious patterns. |
| internal/rt/fastmem.go | safe | Code uses unsafe pointer arithmetic for performance but contains no malicious patterns such as data exfiltration, credential theft, or remote code execution. |
Frequently asked questions
Is github.com/cloudwego/base64x safe to use?
No confirmed malware was found in github.com/cloudwego/base64x@v0.1.6, but the review flagged 12 medium, 5 low severity findings for risky patterns worth checking before you rely on it.
Does github.com/cloudwego/base64x contain malware?
No malware was identified in github.com/cloudwego/base64x@v0.1.6 when Togoder Security scanned it on Oct 5, 2026. A new version can still introduce malicious code, so scan the exact versions in your lockfile.
How was github.com/cloudwego/base64x checked?
Togoder Security downloaded the published Go package and had an AI model read its 17 source files, looking for install scripts, credential access, network exfiltration, obfuscation, backdoors and crypto-wallet theft. The results are cached by file hash and shown here.
How do I scan github.com/cloudwego/base64x together with the rest of my dependencies?
Upload your lockfile at https://security.togoder.click/scan or call the API documented at https://security.togoder.click/api-docs. Files that have already been scanned, like the ones in github.com/cloudwego/base64x@v0.1.6, cost nothing.