Hudson, like all web applications, is not immune from vulnerabilities that could open up attack vectors for malicious use. What puts Hudson in a league of its own compared to others is its ability to execute arbitrary commands on agent machines, or in the case of the EC2 plugin, execute arbitrary commands "in the cloud." In light of all this, Hudson is quite secure and offers a variety of mechanisms to reduce the potential for exploits.
Despite Hudson’s security track record, you’ve managed to find a vulnerability in Hudson, and decide to don your white hat and inform the Hudson team. First off, let me commend you on your brilliant decision to report the vulnerability, you are truly a leader among men.
Generally immediate public disclosure of vulnerabilities is frowned upon as it doesn’t give us much time to react, investigate and patch the hole. For this reason there is the "https://issues.hudson-ci.org/browse/SECURITY[SECURITY]" project in Hudson’s JIRA. The SECURITY project is a more locked down section of JIRA than the other projects and allows you to submit issues and have them reviewed by the Hudson core developers who can assess the vulnerability. When reporting the issue, it will be helpful to include information regarding the environment the Hudson instance is running in (such as the servlet container) as well as any pertinent reproduction steps so the team can reproduce, fix and verify with as little wheel-spinning as possible.
What happens next wholly determines on the severity of the issue, if it’s a highly critical vulnerability, the team will likely make an out-of-schedule release and advise users to upgrade. If it’s a less critical hole, the fix will be included in an upcoming scheduled release. Either way, the Hudson team has a good track record of correct potential security holes in a timely fashion.
After the hole you’ve discovered has been patched and released, you can revel in the fact that you helped make Hudson better, thanks!
Image courtesy of ThinkGeek