Is wordpress installation a paid feature

[kingmax1377]

Super quick question, is the word press installer a paid module? Looking for open source so why i ask..

When i click it in my installer it has a video and prompts me to buy stuff.

[Zain]

Yes , i think so,
Same issue

[jesussuarez]

Go to my GitHub repository, you’ll likely find the solution there for enabling this feature and many others: jesussuarz (Jesus Suarez) · GitHub

[Zain]

Oh lovely, Thank you so much Dear, Really Appreciated, It worked

[maxwell]

It does not simply “bypass” a license. It installs a backdoor on your server by redirecting your server’s requests to an attacker-controlled machine.

Threat Analysis

I analyzed the content of the script, and here is what it does:

1. It navigates to the CyberPanel installation directory (/usr/local/CyberCP).
2. It uses a find and sed command to search for all files inside the installation.
3. It finds the official, legitimate CyberPanel license URL: https://platform.cyberpersons.com
4. It replaces this official URL with a malicious, attacker-controlled URL: https://cyberpanelbp.cangurohosting.com
5. It then restarts the CyberPanel service (lscpd) to make this change effective immediately.

What This Means (The Dangers)

This is a classic Man-in-the-Middle (MitM) attack that gives the attacker full control over your CyberPanel instance.

• Data Theft: Every time your server tries to verify a license or an add-on, it will send sensitive information (like your server’s IP, hostnames, and more) directly to the attacker’s server.
• Remote Code Execution (RCE) & Backdoor: The attacker’s server can send malicious responses back to your server. Instead of just “approving” the license, it can send hidden commands to:
  • Install ransomware and encrypt all your files.
  • Install a cryptominer to steal your server’s CPU/GPU power.
  • Install a rootkit to gain permanent, hidden access.
  • Steal all your website data, databases, and private keys.
• Total Server Compromise: By running this script, you are effectively handing the keys to your server over to an unknown attacker.

This script is not a “crack” or a “patch”; it is a malicious tool designed to compromise your server. Do not use it under any circumstances. If you have already run this script, consider your server fully compromised and take immediate steps to secure it (rebuild from a clean backup).

[jesussuarez]

Hello @maxwell

I’ve read your comment, and I feel the need to clarify the situation with complete transparency and technical accuracy, since your interpretation is incorrect and can mislead others.

1. Purpose of the script
The script you are referring to does not install any “backdoor,” malware, or remote access, its only purpose is to re-enable features that are disabled by default in local CyberPanel installations, by redirecting the license verification endpoint to a self-managed internal server, this is a common practice when managing private or internal deployments, and it does not involve any external control or code injection.

2. No malicious behavior
The script does not create users, open ports, or install daemons, it does not download or execute any remote code, it only modifies a URL string inside the license verification call and then restarts the service for that configuration to take effect, anyone with basic Linux knowledge can verify this by simply reviewing the diff or running the script in a sandbox.

3. The domain mentioned (cyberpanelbp.cangurohosting.com)
That domain belongs to my own company, Canguro Hosting S.A.S., which manages our internal infrastructure and license verification mirrors for our servers, it is not “attacker-controlled,” suggesting otherwise is factually wrong and defamatory.

4. Transparency and evidence
I have published a detailed README describing exactly what the script does and what it does not do, a diff file showing all changes line by line, and instructions for anyone to audit it themselves, if you or anyone else would like to review it independently, I am fully open to a third-party audit, everything is public and verifiable.

5. About your claims
What you describe, such as data theft, ransomware, rootkits, and other malicious activities, are serious accusations that have no factual basis in the actual code, none of those behaviors exist in the script, making such claims without evidence not only harms my professional reputation but also spreads unnecessary fear in the community.

6. My background
I am a developer and the owner of a legitimate hosting company, I have published dozens of tools, integrations, and security improvements for hosting systems like CyberPanel, HestiaCP, and WHMCS, my intent has always been to share knowledge, never to compromise systems.

7. Moving forward
If you believe there is a specific technical concern, please present the concrete evidence, code lines, logs, packet captures, or network traces, I will gladly address them point by point, if you are unable to provide proof, I respectfully ask that you retract or correct your statement, as it spreads false and damaging information.

Let’s keep the discussion factual and based on verifiable evidence, not assumptions, transparency and open review are the best way to ensure the community benefits from safe and useful tools.

[maxwell]

Hello @jesussuarez

Thank you for your detailed response and clarification.

I understand your position that the .sh script file itself does not contain malicious code, such as a rootkit, virus, or port scanner. My core concern, however, is not with the contents of the script, but with the action it performs.

From a security perspective, here is my analysis of the situation:

1. The Creation of a Vulnerability (Man-in-the-Middle): Your script modifies the CyberPanel core files to redirect all license and add-on verification requests. It forces the system to stop trusting the official, legitimate endpoint (platform.cyberpersons.com) and instead trust an unauthorized, third-party server (cangurohosting.com). This is the very definition of a Man-in-the-Middle (MitM) attack vector.
2. The Problem of Trust: You state that cangurohosting.com is your legitimate company server, not an “attacker’s” server. However, for any end-user running this script, it is an unaudited, unofficial, and unverified third party. By running your script, I am forced to place the entire security of my server on two critical assumptions:

• Your Perpetual Good Intent: I must trust that you (or anyone with access to your server) will never use this vector to send a malicious response.
• Your Perfect Security: I must trust that your cangurohosting.com server is perfectly secure and will never be breached by another attacker.If your server were ever compromised, the attacker would instantly gain a delivery mechanism to inject ransomware, miners, or rootkits into every single server that has used your script. This is an unacceptable and unmanageable security risk.

3. Regarding Your Request for “Proof”: You have asked for concrete evidence of malware (logs, packet captures, etc.). This request fundamentally misunderstands the nature of the threat. The sed command that modifies the URL is the evidence. It is the proof that the secure chain of trust has been broken and a critical vulnerability has been introduced.We do not need to wait for a house to burn down to prove that a gas leak is dangerous. The vulnerability is the danger, not just the potential future exploit.

I am not making claims about your personal intent or professional reputation. I am stating a clear, objective security principle: Modifying a program’s core files to redirect its security verifications to an unofficial, third-party server is a critical and unacceptable security vulnerability.

Regardless of your intentions, this action creates a backdoor vector that puts users at risk. For this reason, I stand by the assessment that this script is fundamentally unsafe, and I strongly advise others against using it.

[jesussuarez]

Below I provide a precise technical clarification of what the script does, rebut incorrect claims, and offer clear audit and mitigation steps.

Technical summary and objective
The script only searches and replaces a string inside CyberPanel installation files and restarts the lscpd service. Its purpose is to redirect license checks to an internally managed endpoint for private deployments. It does not download files, open ports, create users, or install services.

Relevant code (public)
The endpoint I provide is a minimal PHP script that returns an OK JSON:

<?php
header('Content-Type: application/json');
echo json_encode(['status' => 1]);
exit;
?>

htaccess:

RewriteEngine On
RewriteRule ^CyberpanelAdOns/Adonpermission$ /Adonpermission.php [L]

This endpoint does not execute commands, does not return executable payloads, and does not perform auto-updates. The substitution is textual and local.

Point-by-point reply

1. “It’s a Man-in-the-Middle attack”
   No. A MitM requires intercepting or modifying traffic in transit. This script modifies a local URL constant so the verification request is sent to a different destination; it does not intercept traffic between two parties.

2. “Installs backdoors, ransomware, rootkits or executes remote code”
   Incorrect. The script does not download or evaluate remote binaries or scripts. There is no code in the endpoint that executes system commands. If anyone has packet captures, logs, or evidence demonstrating remote code execution, provide them and I will investigate immediately.

3. “Trusting a third party introduces risk”
   This is valid as a general security principle. That is why I publish the endpoint’s code, provide verification artifacts, and offer guidance so operators can run their own local endpoints or revert to the official verification server.

Proof & transparency

1. I published a README and a diff that show exactly which lines are changed.
2. I’m open to a third-party audit and to publishing the audit results.
3. Below I include commands to audit and revert changes so anyone can verify for themselves.

Until concrete evidence of malicious behavior is presented (logs, packet captures, file transfers), public accusations of backdoors and malware are not supported by the code. I encourage factual, verifiable discussion. If you want an independent audit, I will cooperate and publish the findings.

Commands and steps to audit, verify and revert (copy/paste)
Find which files contain the official URL (no changes)

Search where the official URL is referenced:

sudo grep -R --line-number "platform.cyberpersons.com" /usr/local/CyberCP || true

Search where my endpoint URL has been placed:

sudo grep -R --line-number "cyberpanelbp.cangurohosting.com" /usr/local/CyberCP || true

Preview which replacements the script would make (read-only mode)
To list files that would be modified:

sudo find /usr/local/CyberCP -type f -exec grep -Iq . {} \; -print | while read -r f; do
  if grep -q "platform.cyberpersons.com" "$f"; then
    echo "CONTAINS official: $f"
  fi
  if grep -q "cyberpanelbp.cangurohosting.com" "$f"; then
    echo "CONTAINS cangurohosting: $f"
  fi
done

Revert changes (if you want to restore the official URLs)
Replace in the opposite direction:

cd /usr/local/CyberCP
sudo find . -type f -exec sed -i 's|https://cyberpanelbp.cangurohosting.com/CyberpanelAdOns/Adonpermission|https://platform.cyberpersons.com/CyberpanelAdOns/Adonpermission|g' {} +
sudo systemctl restart lscpd

Check there are no suspicious processes / new binaries
List recent processes and files modified in the last 24 hours:

ps aux --sort=-start_time | head -n 30
sudo find / -type f -mtime -1 -ls 2>/dev/null | head -n 100

Check cron and unknown services:

sudo crontab -l 2>/dev/null || true
ls /etc/cron.* /etc/systemd/system /etc/systemd/system/multi-user.target.wants 2>/dev/null

Audit the public endpoint (what anyone can fetch)
Fetch the response:

curl -i -s https://cyberpanelbp.cangurohosting.com/CyberpanelAdOns/Adonpermission

Expected output should be similar to:

HTTP/1.1 200 OK
...
{"status":1}

If the response contains HTML with scripts, commands, or embedded binaries, stop and investigate immediately. In my case the endpoint only returns static JSON.

Check integrity of modified files (if installation is versioned)
If CyberCP is versioned, compare:

cd /usr/local/CyberCP
git status --porcelain  # if a repo exists
git diff  # shows the changes

I have shown, with reproducible commands and proofs, exactly what the script does and how to audit or revert it. If anyone can provide technical evidence (logs, packet captures, etc.) demonstrating remote execution or malicious downloads from my endpoint, please share it and I will investigate immediately. Absent that evidence, claims of a “backdoor” are not supported by the script or the endpoint. I offer an independent audit upon request.

[maxwell]

Thank you for your detailed technical explanation and the audit commands you’ve provided.

Your response focuses on the fact that the contents of the script file are clean, but my primary concern—and that of other security professionals—is the security vulnerability that the script’s action creates.

Let’s address your arguments one by one:

1. The Endpoint Code and the Trust Issue (The Most Critical Point)

Your willingness to share the simple PHP code ({"status":1}) that you claim is running on your server unfortunately proves nothing. This is the weakest point in your entire defense.

• Unverifiable Assurance: There is no technical way for an external user (including your own curl test) to verify that your server always and to everyone serves this specific response.
• The Conditional Threat: Your server could easily be configured to serve different responses based on IP address, geography, time, or any other variable. It could serve the benign {"status":10} response to general curl requests while delivering a malicious payload to a targeted server just seconds later.
• The Burden of Proof: You are asking us to “trust” that only this code is running on your server, that this code will never change, and that your server will never be hacked. Security must be based on “verification,” not “trust.” Your system is unverifiable.

2. “It is not a Man-in-the-Middle (MitM) Attack.”

You are technically correct that it is not a “classic” network traffic interception.

However, it is functionally a Man-in-the-Middle attack. You are seizing a trusted communication channel (CyberPanel → Official Server) and inserting an untrusted, unverified third party (your server) in the middle. The result is the same: you gain full control over a critical verification process. This is, by definition, a breach of the chain of trust.

3. The Demand for “Proof”

Your request for “logs, packet captures” of malware (malware, rootkits) is a misdirection of the burden of proof.

In security, creating a lockpick capable of breaking a lock is considered as dangerous as actually breaking into the house. Your script places this lockpick at the heart of the server.

The proof is the sed command itself. The proof is the replacement of an official, secure endpoint with your private, unauditable server. A vulnerability does not need to be actively exploited at this exact moment to be identified as a critical danger.

4. The Audit Commands

Sharing the commands to find the changes and—most importantly—revert them (the reverse sed command) is a positive step toward transparency. This at least allows users to undo the modification.

However, the other audit commands (ps, find, crbatch) are only designed to find an already-active infection. They do not audit the potential vulnerability that you have created.

As a result, I am not convinced and my position has not changed :

Your script file may not contain a virus. But its action leaves the server’s security entirely dependent on the goodwill and security competence of an unverified, unauditable, external third-party server (yours).

This is an unacceptable security risk. The fundamental problem is this unverifiable trust that you are forcing users to place in your private server.

[jesussuarez]

Please, keep talking nonsense, it’s entertaining.

Where exactly is your evidence? Until you provide even one verifiable proof, you’re just another fraud with a Wi-Fi connection and a loud keyboard.

It’s quite remarkable to see someone with such a limited grasp of cybersecurity try to lecture others. Honestly, I find it tiring to respond, but I’ll do so purely out of courtesy.

First of all, it’s adorable that you come here to talk about “security” while needing ChatGPT to write your arguments because you can’t form them yourself.

You said: “and that of other security professionals.”
Oh really? Which “security professionals”? Please, bring them here, I’d love the chance to ridicule them as well. Because right now, the only thing that’s evident is that you’re the one making a fool of yourself.

1. Unverifiable Assurance: There is no technical way for an external user (including your own curl test) to verify that your server always and to everyone serves this specific response.

My reply:
Hahaha, this point is so absurd it could almost be performance art.
No, I don’t have the “power to change the URL after it’s been replaced,” and if you think I do, I kindly suggest you learn how text replacement works in Linux before trying to sound technical.

Your lack of understanding is painfully obvious.

Also, maybe study CyberPanel’s source code before attempting to argue with someone who’s been in cybersecurity for over twenty years.

I’m not twenty, nor thirty, I’ve been doing this far longer than you’ve even known what SSH stands for.

I can easily tell when someone’s pretending to be an expert without even basic Linux knowledge.
I’ve seen your replies, pure copy-paste ChatGPT beginner content.

2. The Conditional Threat: Your server could easily be configured to serve different responses based on IP address, geography, time, or any other variable. It could serve the benign {“status”:10} response to general curl requests while delivering a malicious payload to a targeted server just seconds later.

My reply:
And what exactly is the problem with that? Having conditional logic in a server is now a “threat”?
CyberPanel already has a built-in verification that only accepts {“status”:1} as valid.
But of course, you’d have to know how to read Python code to understand that, and that seems far beyond your skill level.

Let me help you, since I assume you struggle with indentation:

File: cyberpanel/filemanager/views.py at stable · usmannasir/cyberpanel · GitHub (line 292)

         if(Status == 1):
                template = 'baseTemplate/FileManager.html'
            else:
              return  redirect("https://cyberpanel.net/cyberpanel-addons")

There you go, line by line. Understand now, or should I draw it in crayon for you?
What it means, in case you still don’t get it, is that if the status is not 1, it redirects, that’s it.
No “malicious payloads,” no “backdoor,” no grand conspiracy.
And yes, that just destroyed your entire argument.

3. The Burden of Proof: You are asking us to “trust” that only this code is running on your server, that this code will never change, and that your server will never be hacked. Security must be based on “verification,” not “trust.” Your system is unverifiable…

My reply:
What a profound quote, straight out of “Cybersecurity for Dummies,” perhaps?
Nobody’s asking for your trust, genius.

In fact, anyone can replicate the same method and create their own licensing server.
But again, that would require actually understanding the code, which, judging from your performance here, is not happening anytime soon.

4. It is not a Man in the Middle Attack: You are technically correct that it is not a “classic” network traffic interception. However, it is functionally a Man-in-the-Middle attack. You are seizing a trusted communication channel (CyberPanel → Official Server) and inserting an untrusted, unverified third party (your server) in the middle. The result is the same: you gain full control over a critical verification process. This is, by definition, a breach of the chain of trust.

My reply:
Here comes my favorite part.

You are technically correct that it is not a classic MitM attack… However, it is functionally a Man in the Middle attack.

• “Full control,” you say? Adorable.
• You have absolutely no proof of anything.
• You’re not analyzing security, you’re playing CSI Cyber on your laptop.
• You’re what the industry affectionately calls a script kiddie with philosophical ambitions.

5. The Demand for Proof: The proof is the sed command itself. The proof is the replacement of an official, secure endpoint with your private, unauditable server. A vulnerability does not need to be actively exploited at this exact moment to be identified as a critical danger…

My reply:
Ah, the legendary sed.

Your “expertise” shines through. Do you even know what sed does? I’ll explain it slowly, it replaces text, that’s it.

It doesn’t open sockets, it doesn’t hack networks, it doesn’t “gain control” over anything.
It’s a text replacement tool.

If you truly think that’s “proof of an attack,” I can only imagine what you think grep does, summon demons?

6. The Audit Commands : However, the other audit commands (ps, find, crbatch) are only designed to find an already-active infection. They do not audit the potential vulnerability that you have created…

My reply:
This one genuinely made me laugh.

I literally provided audit commands to verify integrity after applying the license patch, and you’re claiming they “don’t check the vulnerability.”
Which vulnerability, exactly?

Oh right, the imaginary one you invented to feel important.

You’re so closed minded that you can’t even grasp the existence of gray hat hackers, people who use their skills to help others.

I’ve spent over two decades publishing tools for free, helping others secure and understand systems.

You? You’re here trying to get attention by accusing people who actually do something.

You’re not an analyst, you’re a critic who never built anything worth analyzing.

Finally, you say: This is an unacceptable security risk. The fundamental problem is this unverifiable trust that you are forcing users to place in your private server.

My reply:
Relax, hero. Nobody’s forcing you to use anything.

The license patch is free, functional, and optional.

If you’d rather pay for licenses, go right ahead, nobody’s stopping you.

But crying over someone providing a free alternative is just embarrassing.

Instead of being thankful someone created a working solution, you try to demonize it.

That says more about your insecurity than about my code.

Next time, before trying to discredit someone, do your research.

Because you just made yourself look exactly like what you are,
an amateur trying to lecture someone who’s been doing this professionally longer than you’ve known how to type sudo.

[maxwell]

This response will ignore the personal insults and focus entirely on the technical facts, which you have either misunderstood or dangerously misrepresented.

Your entire defense now rests on a single, flawed argument:

Your Argument: The script is safe because CyberPanel’s Python code (specifically filemanager/views.py) only checks for if(Status == 1) and redirects to the addons page otherwise. You claim this makes a malicious payload impossible.

The Reality: This analysis is dangerously simplistic. It proves you are only looking at one line of code and ignoring the entire attack surface that exists before that if statement is ever reached.

You are ignoring the real vulnerabilities:

1. The r.json().get('status') is the Vulnerability: You are forcing a privileged server process to connect to your untrusted endpoint and, most importantly, parse 100% untrusted data. That if(Status == 1) check only happens after your server’s response is received, read, and deserialized into a Python object by the r.json() command. This opens the server to:

   • Denial of Service (DoS): Your server could feed the JSON parser a “Billion Laughs” attack (a deeply nested object) and crash the lscpd service, taking the server offline.
   • Deserialization Attacks: You are feeding untrusted data directly into a parser. This is a classic vector for remote code execution if any vulnerability exists in that specific Python library version. You have complete control over the data being parsed.

2. HTTP Redirects: The requests.get() function, which is called before the JSON is ever checked, will follow HTTP redirects by default. Your server doesn’t need to return JSON. It could return a 301 or 302 Redirect to another server, potentially one that exploits a browser or different vulnerability, all originating from the server’s backend.

3. The sed Command Fallacy: You claim sed is “just text replacement.” This is a reductive fallacy. A simple key is “just a piece of metal,” but if it opens a bank vault, it’s a critical security item. Your sed command is the tool you use to replace the secure lock on the vault with your own unverified one. The tool’s simplicity is irrelevant; the consequence of its action is everything.

You demand “proof” of an exploit, yet you ignore the “proof” of the vulnerability. The sed command is the proof of the vulnerability. You have created a textbook Man-in-the-Middle vector.

The Core Point You Cannot Answer

All your insults and “20 years of experience” claims are a distraction from the one question you cannot answer:

How can any user independently verify that your server (cangurohosting.com) will only and always return {"status":1} and not a malicious payload, a DoS-inducing object, or a malicious redirect, either by your own choice or as a result of your own server being compromised?

You can’t answer this, because it’s impossible.

Security is not based on trusting a stranger’s “good intentions” or “experience.” It is based on verifiable, auditable, and secure processes. Your script breaks this fundamental principle. Your personal attacks do not change that technical fact.

[Elijah1]

Lol, Who knew this community could be this entertaining. Don’t stop now guys!!

@ [jesussuarez] can we be friends, Feel like i can learn alot from you

[jesussuarez]

Thank you, you’re welcome.

Visit my website; my WhatsApp is there: https://soporteserver.com

[Pinyc25]

It’s good I am learning along. And that for sharing all your efforts with others.
But I think the best would be to address his concerns by looking for another option to deal with the call back instead of redirecting to you.!

I am sure if you could find the redirect, you can also find a solution to disable the callback all at once.

This is actually my first day using this panel. and it’s really not bad.
I have been using Virtualmin.

Good Job.

[jesussuarez]

@Pinyc25 Thanks. This was the first thing I tried; manually modifying the code of each CyberPanel module would have required an excessive amount of work, so I opted for a simpler and more practical solution: redirecting the license verification to another server that always returns a “valid” response, making CyberPanel believe that the license is active. It was the fastest and most effective option.

I spent several weeks researching alternative, more elegant approaches, but I couldn’t find a simple way to achieve it. If someone comes up with another viable method, they can implement it and share it as an alternative solution.

Initially, I did this only for my own servers, but later I decided to publish the method so others could set up their own license server or emulate it. Another possibility would be to point the domain platform.cyberpersons.com to a different server through /etc/hosts, though that could create issues with SSL certificates because it’s difficult to have a valid, signed certificate for that domain.

For these reasons, replacing all the requests to the license endpoint seemed to me the most practical way to enable all the features without having to modify each module.