I have a file that a friend/hacker was able to create called \'AND SELECT * FROM \'users\'\'
The FTP command DELE \'AND SELECT * FROM \'users\'\' says this:

Command:    DELE \'AND SELECT * FROM \'users\'\'
Response:   553 Prohibited file name: \'AND SELECT * FROM \'users\'\'

That means it can't delete a file with an SQL injection as its name.
Any ideas on how to delete the file? I need help.
P.S. The file is on a remote ftp server, so i cannot go into the hard disk and delete it directly.

Dani AI

Generated

A file with embedded quotes and SQL-like text was created on the remote FTP server (reported by ) and the server is rejecting deletion as a "prohibited filename." This usually means the FTP daemon or host-side policy treats the name as unsafe so it refuses to act on it rather than executing anything SQL-related. 's idea of moving known-good files and performing a bulk removal is a valid recovery path, but it carries data-loss risk unless a verified backup exists.

Practical, low-risk sequence to try before escalating:

  • Capture the exact raw name as shown by the directory listing (copy the listing line). Some clients alter quoting, so the raw-name must match the server view.
  • Use the FTP client's raw/quote mode to issue rename commands (RNFR/RNTO) and then delete the safe name. Placeholders shown below should be replaced with the exact listing text when sending raw commands.
# send raw FTP commands (example placeholders)
quote RNFR <exact-name-from-LIST>
quote RNTO safe_name.tmp
quote DELE safe_name.tmp

If RNFR/RNTO or quote-mode fails, next steps depend on available access: a control-panel file manager, SFTP or SSH shell access will remove the filename reliably. When shell access exists, removing by inode avoids character-escaping problems:

# on a shell (example placeholders)
ls -li
find . -inum <inode-number> -exec rm -i {} \;

If no higher-level access is available, the hosting provider or server admin must remove the file.

Operational notes: moving many files out before bulk deletion is useful but double-check backups first (as suggested). Treat such a filename as an indicator of a possible malicious upload; scan for other unexpected files, review webserver/upload logs, rotate credentials, and patch any vulnerable upload endpoints.

Recommended Answers

All 2 Replies

Why not move all files you need to keep and try a (m)delete *

Or perhaps DELE "\'AND SELECT * FROM \'users\'\'" may work, depending on the FTP server.

Thanks. I'll try it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.