When copy-to-slave plugin is installed in the system, anyone with create/edit job permission can enable it for a job, set HUDSON_HOME as a base dir, then fetch config.xml and cat it to build log for example. Global config.xml may contain highly sensitive data like EC2 and other credentials.

More details, copied from https://wiki.jenkins-ci.org/display/JENKINS/Copy+To+Slave+Plugin?focusedCommentId=59509028#comment-59509028 :

Jenkins allows to have access separation, where only users with admin permissions haev access to global config. However, with this plugin installed, any user who has job create/edit permission can fetch Jenkins' config.xml, and that may contain sensitive data, like EC2 credentials for example.

That's why carefully written plugins split there config in 2 parts: global config where arbitrary paths, credentials, etc. are set, job config, where usually user can just select a choice from predefined set using a dropdown.

Suggestions for alleviating immediate security threat: remove "HUDSON_HOME" option, replace it with "HUDSON_HOME/copyToSlave" option. The latter option is still required to preserve generality of plugin, as "HUDSON_HOME/userContent" is not suitable for all content, as it is publicly accessible via http://<jenkins>/userContent. "Job's workspace on master" on its own is not enough either, as for the case of hundreds of jobs all requiring same prerequisites, it's very cumbersome to configure each job's workspace.

And well, this assumes that you didn't try to patch Ant's file pattern code which by all means should prohibit ".." syntax to access files outside of the specified prefix, because otherwise this plugin can be used to access any file on master's filesystem which is very big security risk.

More elaborated approach would be of course to split plugin config to global/per-job parts, where in global and admin can define set of base paths (which can be arbitrary then), and in job config, a user can select just from these predefined ones.