Page MenuHomePhabricator

https://wm-bot.wmcloud.org/github/index.php seems vulnerable to SQL injection
Closed, DeclinedPublicSecurity

Description

I haven't tested myself whether SQL injection is actually possible on the live site, but:

Therefore, from reading the code, I suspect that it would be possible to perform SQL injection through https://wm-bot.wmcloud.org/github/index.php by POSTing a request body similar to the following:

{
  "repository": {
    "full_name": "' OR sleep(5);--"
  },
  "commits": [
    {
      "url": "https://example.com",
      "id": "1234",
      "message": "commit message",
      "author": {
        "username": "example-user",
        "name": "example",
        "email": "example@example.com"
      }
    }
  ]
}

Details

Risk Rating
Medium
Author Affiliation
Wikimedia Communities

Related Objects

Event Timeline

I will leave it to the Security-Team to add other relevant tags/subscribe relevant people here, if that's okay.

sbassett changed the task status from Open to In Progress.Nov 3 2025, 5:29 PM
sbassett assigned this task to mmartorana.
sbassett triaged this task as Medium priority.
sbassett added a project: SecTeam-Processed.
sbassett moved this task from Incoming to In Progress on the Security-Team board.

Hey cloud-services-team - this looks like a potential vulnerability. What mitigation approach do you want to take?

Also, there’s currently no code owner. We should try to assign one according to the new code-ownership policies and avoid the service being shut down.

Thanks!

dcaro subscribed.

Hi! This is a project hosted in CloudVPS, not CloudVPS itself, the maintainers for the wm-bot project are listed in the pages https://meta.wikimedia.org/wiki/Wm-bot and http://openstack-browser.toolforge.org/project/wm-bot

@Petrb is the one with write access on the repo.

@Petrb is the one with write access on the repo.

More specifically T283249#7105898 is a list of those with repo access

Hey @Petrb - based on the codepath above this still looks like a plausible SQL injection vector. Could you confirm whether you plan to patch this upstream, or if there’s anything needed from our side to help move it forward?

Thanks

Hey cloud-services-team and @dcaro - this service has a known vulnerability. Since there are currently no mitigation steps and no identified code owner, the Security-Team strongly recommends shutting the service down.

Since this is outside our team’s scope, we’re flagging this to the responsible team for action.

Hey cloud-services-team and @dcaro - this service has a known vulnerability. Since there are currently no mitigation steps and no identified code owner, the Security-Team strongly recommends shutting the service down.

Since this is outside our team’s scope, we’re flagging this to the responsible team for action.

At this point, I likely will just disable the GitHub plugin, since it doesn’t see a lot of use.

Hey cloud-services-team and @dcaro - this service has a known vulnerability. Since there are currently no mitigation steps and no identified code owner, the Security-Team strongly recommends shutting the service down.

Since this is outside our team’s scope, we’re flagging this to the responsible team for action.

At this point, I likely will just disable the GitHub plugin, since it doesn’t see a lot of use.

GitHub plugin is now disabled.

For the record, only 1 repo was actually configured with the plugin, and i'm not even sure that the plugin was even working correctly.

GitHub plugin is now disabled.

Out of interest, what does disabling the GitHub plugin entail / what result does it have in practice? Only asking as the https://wm-bot.wmcloud.org/github/index.php endpoint still seems to be responsive to an (empty) request, and it's hard to know how to safely test whether or not the SQL injection is still likely an issue. (Do I have permission to test the endpoint with the sleep SQL payload I included in the task description?)

$ curl -X POST https://wm-bot.wmcloud.org/github/index.php -d {} -i
HTTP/2 200 
server: nginx/1.22.1
date: Wed, 17 Dec 2025 08:25:19 GMT
content-type: text/html; charset=UTF-8
content-length: 15
strict-transport-security: max-age=31622400
x-clacks-overhead: GNU Terry Pratchett
permissions-policy: browsing-topics=()
report-to: {"group": "wm_nel", "max_age": 604800, "endpoints": [{"url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0"}]}
nel: {"report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}

Unknown payload

GitHub plugin is now disabled.

Out of interest, what does disabling the GitHub plugin entail / what result does it have in practice? Only asking as the https://wm-bot.wmcloud.org/github/index.php endpoint still seems to be responsive to an (empty) request, and it's hard to know how to safely test whether or not the SQL injection is still likely an issue. (Do I have permission to test the endpoint with the sleep SQL payload I included in the task description?)

$ curl -X POST https://wm-bot.wmcloud.org/github/index.php -d {} -i
HTTP/2 200 
server: nginx/1.22.1
date: Wed, 17 Dec 2025 08:25:19 GMT
content-type: text/html; charset=UTF-8
content-length: 15
strict-transport-security: max-age=31622400
x-clacks-overhead: GNU Terry Pratchett
permissions-policy: browsing-topics=()
report-to: {"group": "wm_nel", "max_age": 604800, "endpoints": [{"url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0"}]}
nel: {"report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}

Unknown payload

Testing is fine with me. By disabling I mean that the bot is no longer loading the plugin (nobody can setup a repo). I can make that endpoint inaccessible if needed.

Testing is fine with me.

Thanks for confirming :)

Currently, I'm getting HTTP 500 errors when I try to test this vulnerability; but it doesn't appear that any stacktraces/exception messages are displayed, so to be honest it's hard for me to actually know whether this vulnerability is currently exploitable in practice or not (as I don't know for certain what's causing the error, and therefore don't know whether or not it'd be possible to work around it).

I can make that endpoint inaccessible if needed.

Personally I would say that making the endpoint inaccessible (until it's confirmed that any possible SQL injection vuln has been fixed) would probably be a good solution, as AFAICS that would guard against any way of using the code in the relevant file to perform SQL injection. The Security-Team/other folks may have their own opinions, though.

PHP Fatal error: Uncaught mysqli_sql_exception: Connection refused

Looks like i never actually successfully configured the connection info anyway. That would mean that the exploit isn't usable since we can't successfully connect to the db.

I have now set the permissions on index.php to 600, meaning it now cannot be accessed due to permissions.

PHP Fatal error: Uncaught mysqli_sql_exception: Connection refused

Looks like i never actually successfully configured the connection info anyway. That would mean that the exploit isn't usable since we can't successfully connect to the db.

I was going to say; at least it turns out that this isn't actually exploitable in practice :D
I guess this task can maybe be made public (& resolved, unless you'd like this to stay open for fixing the actual code) now? The SQL injection bug should still probably be fixed prior to this endpoint going live again/its SQL credentials being configured, but as of right now there thankfully doesn't seem to be an exploitable issue.

sbassett subscribed.

I was going to say; at least it turns out that this isn't actually exploitable in practice :D
I guess this task can maybe be made public (& resolved, unless you'd like this to stay open for fixing the actual code) now? The SQL injection bug should still probably be fixed prior to this endpoint going live again/its SQL credentials being configured, but as of right now there thankfully doesn't seem to be an exploitable issue.

Ok, good to know. Since there's not actual vulnerability at this time - because the tool isn't even connecting to a database and therefore not working properly - I'm going to decline this for now and make it public.

sbassett changed Author Affiliation from N/A to Wikimedia Communities.Jan 6 2026, 4:40 PM
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Medium.
sbassett moved this task from In Progress to Our Part Is Done on the Security-Team board.