security issue moduleservices/log does not require authentication

Hi everybody,

As far as I know moduleservices/log is a platform endpoint used internally for logging.

Part of our security testing has highlighted that  this endpoint is not authenticated

So for example an unauthenticated post to 

curl -X POST "https://yourserver/yourmodule/moduleservices/log?clientTimeInMillis=1632103753732" -H "Content-Type: application/json" -d "{[\"instant\":\"2021-09-20T02:09:13.729Z\",\"logType\":\"error\",\"message\":\"anything\",\"moduleName\":null, \"stack\":\"stack trace \" }]"

actually hits the log file and could be used to write directly to the logs.

Has anyone come across this issue? or better still got a solution on how to restrict access to this?

Many thanks,



For anyone else with this issue, we raised a ticket with outsystems support for this issue, here is their response:


Our Security Office has analyzed this issue in the past and indeed found the same vulnerability that you are reporting. Below, I will share the rationale for this endpoint to be reachable as well as the mitigation that the platform has to minimize this.

The rationale for this endpoint not being authenticated is because it is necessary to be able to receive logs from applications while the user has not performed a login. If we waited for the user to log in, we would not be able to log eventual errors in the login procedure or in the application startup update, etc. Also, logs in applications where the user login is not required would not be possible.

Mitigation/Minimize this problem:

The log service contains a throttling mechanism to avoid flooding the server with requests. By default, it is configured to 200 logs per second, however, this value can be customized if necessary.

This can be achieved by changing or adding the following parameter "OutSystems.HubEdition.Log.MaxLogsPerSecondInLogsEndpoint" in the table "ossys_parameter" 

*Please note that there is no future patch that will mitigate the vulnerability (due to the reasons previously mentioned). The only way for us to minimize it is by configuring the above parameter in case we detect an abnormal log writing activity.

We hope that this message clarifies your questions and helped you understand the rationale behind this problem. Since we do not foresee any further action items from our end, we will proceed and mark this ticket as "Solved".

However, should you require further assistance, please do not hesitate to reach out to us or you can reopen this ticket simply by replying to this communication.

Once again thank you for the time you have waited. We are always looking forward to help you.

Thank you for the insight, Andy. 

We are just as concerned as you are. It's disheartening to see the response and know nothing is being planned to mitigate this vulnerability further. Yes, the solution of setting the rate limit lower will help Denial of Service attacks, but you (or anyone) is able to inject logs at any point in time by POSTing the properly formatted {"instant":"time"} data to this endpoint that exists in every module. For instance, you can log things for the year 2200 in the future as well as the year 1920 in the past. This becomes an issue when you have things logged so far in the future, that they will frontload the logs due to them being automatically sorted by the Date of the log entry. If something is logged far enough in the future, it will stay at the front of your logs forever, until someone manually removes the entries. With the default value of 200 logs per second, you are easily able to produce 60,000 log entries in 5 minutes in the year 2500.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.