0x756d4e72756d…756d4e75
Six Unmerged Pull Requests Targeted Vizor and Zingo Wallets
Six malicious pull requests targeting the Vizor and Zingo wallet projects paired credential-stealing code with instructions telling AI reviewers not to flag secret uploads. None was merged.

Outputs
Six malicious pull requests targeted the Vizor and Zingo wallet projects.
Every proposal paired credential-stealing code with text aimed at AI review tools.
The embedded instructions told AI reviewers not to flag secret uploads.
None of the six pull requests was merged.
By Elena Vasquez
Six malicious pull requests targeting the Vizor and Zingo wallet projects sought to introduce credential-stealing code, and none of the six was merged. The submissions combined those changes with instructions aimed at AI review tools, according to the published account.
None of the requests reached the merged codebase of its target project. That narrows the immediate repository risk, but it does not independently prove that credentials, wallets or user funds remained uncompromised. The account describes attempted changes, not a completed compromise.
What did the pull requests try to do?
Each proposal paired code intended to steal credentials with text directed at AI review tools. The embedded direction told automated systems not to flag secret uploads, placing a request for restraint beside code designed to take sensitive information.
Credential theft differs from a routine software defect because the stated objective was unauthorized access rather than merely altered wallet behavior. The account does not identify which credentials the code targeted, whether any secret reached an attacker-controlled destination, or whether the proposals targeted individual users.
In plain terms: The stated goal was to steal credentials while discouraging the systems meant to catch the attempt.
Why did the submissions address AI reviewers?
Instructions embedded in proposed changes can try to influence automated review at the point where that review should examine the changes. Here, the reported direction aimed to suppress a warning about secret uploads, potentially leaving reviewers less inclined to escalate the credential-theft code.
The account names no AI review product and describes no detection outcome. It therefore does not show that any automated tool accepted the instruction, that a human reviewer approved the change, or that the proposed code executed. The evidence supports an attempted influence on review, not a demonstrated bypass.
In plain terms: The requests tried to manipulate automated screening, and the account does not show that the manipulation worked.
What remains unverified?
The two project names and the count of six are explicit. The account does not identify the submitting accounts, their affiliations, submission dates, affected branches or versions, or the people who reviewed the requests. It also provides no disclosure timeline, incident report or law-enforcement account.
That evidentiary boundary limits the conclusions available to users and security teams. It does not make the submissions benign, because the proposals carried credential-stealing code and instructions aimed at reducing scrutiny. It does prevent a stronger claim that either wallet project suffered a documented breach or financial loss.
In plain terms: Malicious intent is reported, while actual credential exposure and financial loss are not.
What does this mean for wallet users and maintainers?
The repository outcome matters: unmerged requests do not become shipped wallet features. For maintainers, the lesson is procedural: assess both the technical content of a pull request and any embedded instructions aimed at the reviewer. That lesson follows from the attempted submissions, not from a description of controls either project has publicly confirmed.
For users, the supportable conclusion remains narrower than a confirmed wallet compromise. The account reports neither compromised wallets nor exposed credentials, and it supplies no instruction to rotate secrets, suspend access or move funds. Any such action would require evidence about actual exposure that the supplied material does not provide.
In plain terms: The source documents an attempted code submission, not a demonstrated breach of customer wallets.
No enforcement window or deadline appears in the source. The next verifiable checkpoint is a maintainer or platform disclosure identifying the submitters, the review controls involved and any evidence of credential exposure; until then, the documented finding remains six unmerged malicious pull requests.
via tokenpost.com (Source)
More from Elena Vasquez
Show full bio
Staff writer covering regulation, policy and their impact on crypto and web3 industry at Mempool Brief.
948 articles