A Vibe Coder With No Degree Ended Up in Court. Here Is What the Expert Witness Found.

I saw this post on Threads, regarding a developer who was taken to court in Malaysia for professional negligence. The person sharing the story was the Expert Witness for the prosecution. This was, by their count, their fifth or sixth time appearing as an IT forensics expert in a case like this.

The defendant had opened an IT company. No degree. No professional certification. By their own admission, they had never written "Hello World" from scratch. What they could do was use AI to generate code, paste it together, deploy it, and sell it as a SaaS product to a paying client.

That product is now at the centre of a court case.

What This Case Involves

• A SaaS developer with no qualifications used AI-generated code to build and sell a system to a client.
• Digital forensics uncovered SQL injection vulnerabilities, hardcoded API keys pushed to a public GitHub repo, zero audit logging, path traversal flaws, and third-party packages containing backdoor scripts.
• Under PDPA 2024, any developer who builds, manages code for, and hosts a SaaS system is classified as a Data Processor and is criminally liable for security negligence.
• The legal exposure in this case spans PDPA, the Copyright Act, the Contracts Act, and the Penal Code.
• Maximum penalty under PDPA 2024 for a Data Processor: RM1,000,000 fine or 3 years in prison.

What the Forensic Investigation Found

The expert witness documented eight findings across the codebase and server environment. I will go through each one because individually they are bad enough, but together they tell a story about a system that was never built to handle real data.

SQL injection via string concatenation. The system was querying the database using DB::raw(), whereRaw(), and orderByRaw() with user input concatenated directly into the query. No parameterized queries. No input validation. Laravel comes with prepared statement support by default. Someone actively had to work around it to get this result.

Path traversal on file downloads. The download function accepted a filename parameter from user input and passed it directly to storage_path('app'). No use of Laravel's Storage Facade. No basename() sanitization. An attacker could traverse directories and access files they were never meant to see.

No concurrency controls. The system processed transactions without any locking mechanism. No lockForUpdate(), no sharedLock(), no Redis-based Atomic Lock. Under concurrent load, race conditions could corrupt transaction data.

Production API keys and APP_KEY hardcoded in the main repository. Pushed to a public GitHub repo. Anyone with the link had the keys to the system. This is one of the most elementary mistakes in software development, and the one the community reaction on Threads was most visceral about.

System logging disabled. No audit trail. No record of who accessed what, when, or what changed. If a breach had occurred, there would have been no evidence to reconstruct it. Under PDPA, the ability to demonstrate what happened to personal data is not optional.

No documentation and no testing. The system went to production with no unit tests, no integration tests, and no test records. No evidence that any security review was performed before go-live.

Third-party packages with backdoor scripts. The forensic review found packages from untrusted sources, believed to have been selected by an AI tool that could not verify the reputation of what it was recommending. Some packages contained malicious scripts.

GPL-licensed open source code used without attribution. Copyright notices had been removed. That turns a licensing issue into a Copyright Act violation.

Why This Is a PDPA Issue, Not Just a Bad Code Issue

This is the part I want to be very clear about, because I think a lot of people read this story as an IT quality story. It is not. It is a data protection story.

Under PDPA 2010 as amended in 2024, anyone who builds a system, manages the code, and hosts the server for a client is classified as a Data Processor. Not just the company that owns the data. The developer too.

Data Processors are now directly criminally liable if they fail to meet the Security Principle under PDPA. That means implementing security measures appropriate to the nature of the personal data being processed. SQL injection vulnerabilities and hardcoded credentials in a public repo are not appropriate security measures. They are the absence of security measures.

The amendment did not introduce a vague standard. It introduced criminal liability. A fine of up to RM1,000,000, or three years in prison, or both. That applies to the developer. Not just the company that commissioned the work.

The developer in this case apparently believed that using AI to generate the code meant the responsibility for what the code did also resided somewhere else. It does not. The moment you take a contract to build and host a system that processes personal data, you are a Data Processor under Malaysian law. The tool you used to write the code is irrelevant.

The Other Legal Exposure in This Case

PDPA is just one layer. The expert witness's findings triggered multiple other statutes.

Copyright Act 1987, Section 41(1)(b). Unauthorized reproduction or distribution of copyrighted work. The GPL code with removed attribution falls here. Fine not less than RM2,000 per infringing copy, or up to five years in prison.

Contracts Act 1950, Section 74. Breach of contract with general and special damages. The client is entitled to claim the cost of rebuilding the system, data recovery costs, and business losses caused by the breach. That figure can quickly exceed the original contract value several times over.

Penal Code, Section 417 (Cheating). Deceiving the client about having the competency and capability to deliver a professional system, and in doing so inducing them to share sensitive data. Up to five years in prison or a fine.

Penal Code, Section 419 (Cheating by Impersonation). Presenting as a professional IT services company. Up to seven years in prison or a fine.

This is not one charge. It is several charges stacked on each other, each carrying its own penalty.

The Vibe Coding Question

I want to be careful here, because the comment section on that Threads post had a predictable reaction: "padan muka vibe coders." And while I understand the sentiment, I think it slightly misses the point.

The problem in this case is not that AI was used to write code. Plenty of experienced developers use AI tools to assist them, and that is fine. The problem is that this person had no foundation to evaluate what the AI was producing. They could not tell whether a query was safe. They did not know what a race condition was. They had no instinct to check whether a package was trustworthy or whether a file path was being sanitized.

AI generates code that compiles and runs. That is not the same as code that is safe. The gap between "the system works" and "the system is secure" requires human judgment, and human judgment requires actual knowledge.

When you take a contract to build something for a client, you are taking legal responsibility for what you deliver. That responsibility does not transfer to the AI tool. It does not transfer to the client for commissioning the work. It sits with you.

What Companies Should Do Before Engaging a Developer

From a DPO perspective, the client in this case also had a responsibility they may not have exercised.

If your organisation is procuring a system that will process personal data, you need to treat your developer as a Data Processor under PDPA. That means a written Data Processing Agreement before any work begins. It means asking the right questions during vendor due diligence: What security practices do they follow? Have they built systems of this type before? Can they provide references? What does their testing and deployment process look like?

"They quoted the lowest price and seemed confident" is not due diligence. And under PDPA, if a breach occurs and you cannot demonstrate that you selected and supervised your Data Processor responsibly, your organisation carries liability too.

A properly structured vendor assessment would have surfaced the red flags here before a single line of code was written. No credentials, no references, no documented process. Those are disqualifying factors, not things to overlook in exchange for a cheaper quote.

What This Means If You Are a Developer

If you build systems for clients in Malaysia, here is the practical version of what this case means for you.

You are a Data Processor the moment your system touches personal data. That classification does not care about your job title, your company size, or whether you have a degree. It applies to you the same way it applies to a software house with fifty developers.

The Security Principle requires you to implement appropriate technical and organizational measures. In plain terms: use prepared statements, never hardcode credentials, keep secrets out of public repositories, implement proper access controls, maintain audit logs, test before go-live, and know what is in your dependencies.

These are not advanced skills. They are the baseline. And under PDPA 2024, falling below the baseline is no longer just a professional embarrassment. It is a criminal matter.

If you are taking on clients whose data you will be processing and you are not certain your practices meet the standard, the time to address that is before you sign the contract. Not in a courtroom.