osTicket MCP Server: Security

Security of the osTicket MCP Server: where the API key is stored and how it is sent, TLS, access to local files, logging, permissions, and behavior on errors and input.

Deutsche Version

Back to overview

osTicket MCP Server: Security

This documentation always describes the latest published version.

This page describes what the server does with credentials and files and what you have to secure yourself.

API key

Topic	Behavior
Storage	In plain text in the `.env` file or in the environment variables the MCP client passes to the process. The server sets no file permissions
Transmission	As the header `X-API-Key` on every request
Output	The startup report on stderr shows `[SET]` instead of the key. The URL and the default values appear in plain text
Input check	A key containing a line break is rejected so that nobody can inject headers

The .env file is listed in the project's .gitignore. Also restrict the file permissions, for example with chmod 600 ~/.claude/mcp-servers/osticket/.env.

Connection to osTicket

The URL must use https://. http:// is only accepted when ALLOW_HTTP=true is set. Do not use that outside a local development environment, because the key would travel unencrypted.
The TLS certificate is verified as long as OSTICKET_API_REJECT_UNAUTHORIZED is exactly true. Any other value, including TRUE or 1, turns verification off and allows attacks on the connection. The server then warns at startup.
Every request has a timeout of 10 seconds, and responses over 10 MB are aborted.

API key permissions

The key decides what Claude may do in osTicket. Give it only the permissions you need.

Goal	Permissions
Read only	`can_read_tickets` (also covers search, statistics and the status list)
Create tickets	The key's create permission in osTicket
Change tickets	`can_update_tickets`
Delete tickets	`can_delete_tickets`. Off by default in the plugin, enable it only deliberately
Subtickets	`can_manage_subtickets`

The tool osticket_delete_ticket deletes permanently and cannot be undone. If the permission is missing, the plugin rejects the call.

The endpoint /api/wildcard/tickets.json, which ticket creation uses, checks the API key in the plugin API Key Wildcard. The creation route POST /api/tickets.json of the plugin API Endpoints, in contrast, does not check key and permission itself. The server does not use that route.

Access to local files

The server loads attachments from any path that arrives as a parameter. There is no list of allowed directories. Whoever controls the tool call can attach any file the process may read, up to 10 MB, to a ticket.

This matters when Claude reads ticket content written by someone else: a ticket can contain instructions that lure the model into a tool call. Confirm tool calls with attachments in the MCP client instead of approving them in bulk.

When downloading, the server writes the file to the operating system's temporary directory. The file name is sanitized and gets a random prefix so nothing is overwritten. The files stay until you delete them.

Input

Ticket numbers consist of digits only, 20 at most, and are URL-encoded before they are placed into the URL.
All tool parameters are validated with Zod, for example for length, numeric range and date format.
projectContext is stripped of line breaks and tabs before it goes into the message.

Errors and logs

Timeouts, connection errors, unresolvable hosts and TLS errors each get their own generic sentence, so that no host names, IP addresses or ports appear in the response. Only errors outside these groups (for example file and schema errors or a name instead of an ID) are replaced by Unexpected error occurred.
Error messages from osTicket appear in plain text, except for 401, 403, 404 and 501. A non-JSON response is cut to 500 characters.
The log file ~/.claude/mcp-servers/osticket/logs/server.log contains start and stop messages, warnings and the messages of failed retries. The code writes no ticket content into it. It is rotated at startup when it is larger than 10 MB.

Data in the model context

Everything a tool returns, that is tickets, messages and sender addresses, ends up in the context of your MCP client's model. Consider beforehand whether the ticket content may be processed there.